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THE  ARMY  ADA*  EDUCATION  PROGRAM 


Dennis  J.  Turner 

Center  for  Tactical  Computer  Systems  (CENTACS) 
U.S.  Army  Cammunications-Electronics  Carmand  (CECQM) 
Fort  Monmouth,  New  Jersey 


In  behalf  of  the  U.S.  Army,  CENTACS  is  pursuing  a 
comprehensive  and  aggressive  Ma  program.  An 
important  aspect  of  that  program  is  the  develop¬ 
ment  and  transfer  of  public  domain  Ada  educational 
and  training  materials  which  are  focused  on  the 
needs  of  the  academic,  industrial  and  government 
ccrrmunities.  This  paper  provides  an  overview  of 
the  Army ' s  Ada  education  and  training  program  and 
summarizes  the  products  and  materials  which  are 
being  produced  under  contracts  with  Softech,  Inc. , 
New  York  University  and  Jersey  City  State  College. 


Summary  of  the  CENTACS  Ada  Program 

CENTACS  has  been  actively  supporting  the  DOD  Ada 
initiative  since  1975.  Activities  have  been 
focused  in  five  complementary  areas:  language 
definition,  program  support  environments,  method¬ 
ology,  education  and  training,  and  Policy. 

Language  Definition 

CEKTACS  provided  the  Army  representative  to  the 
DOD  High  Order  Language  Working  Group  (HOLWG) 
which  developed  the  initial  language  requirements. 
Carpeting  designs  led  to  the  selection  of  the  so 
called  GREEN  language  which  was  later  to  become 
Ada,  as  new  defined  in  MIL  STD  1815A.  CENTACS 
contracts  with  Softech,  Inc. ,  Teledyne-Brown 
Engineering  and  New  York  University  have  been 
instrumental  in  the  development  of  the  test 
suite  which  is  now  used  by  the  DOD  Ada  Joint 
Program  Office  (AJPO)  to  validate  that  canpilers 
are  implementing  the  language  definition  correctly. 

Program  Support  Environments 

CENIACS  has  participated  in  the  development  of 
requirements  for  Ada  Program  Support  Environments 
(APSE's).  These  requirements  are  currently 
embodied  in  a  document  known  as  the  STONEMAN. 

In  June  1980,  CECQM  awarded  a  contract  to  Softech, 
Inc.  to  develop  an  Ma  Language  System  (ALS) 
which  combines  the  Ma  and  STONEMAN  initiatives. 
The  ALS  is  a  government  cwned,  production  quality 
Ada  support  environment  which  includes  a  rich  set 
of  powerful  tools  (in  addition  to  a  compiler) 
which  will  dramatically  improve  the  productivity 


of  programmers  and  technical  managers.  The  ALS 
baseline  system  (VAX  host)  is  scheduled  for  com¬ 
pletion  by  the  fall  of  1984  and  additional  tools  in 
support  of  targeting  to  the  Army's  Military 
"arputer  Family  (MCF)  by  December  1985. 

Representatives  have  also  been  participating  in 
the  service  activities  aimed  at  the  development  of 
a  Common  Ma  Interface  Set  (CAIS)  ,  and  the  Joint 
Service  Software  Engineering  Environment  (JS3EE) 
Committee  under  the  Software  Technology  for  Mapt- 
able  Reliable  Systems  (STARS)  initiative. 

CENTACS  is  sponsoring  a  research  effort  which  is 
developing  a  prototype  system  (called  GANDALF)  for 
experimentation  with  syntax  directed  editors, 
intelligent  work  stations  and  distributed  process¬ 
ing,  all  in  an  Ma  context. 

The  development  and  evaluation  of  powerful  support 
environments  are  essential  if  we  are  to  maximize 
the  productivity  of  programmers. 

Methodology 

CENTACS  has  been  pursuing  a  variety  of  methodology 
investigations  since  the  early  70' s.  This  impor¬ 
tant  topic  is  the  focus  of  a  great  deal  of 
research  and  is  a  major  thrust  of  the  STARS  initi¬ 
ative.  The  Army  is  strongly  motivated  to  advance 
the  state-of-the-art  in  this  area  in  order  to 
reduce  costs  thru  effective  methodology  which  can 
be  applied  uniformly  across  systems. 

Education  and  Training 

The  Ma  language  and  its  supporting  environments 
and  methodologies  are,  obviously,  of  little  value 
if  the  workforce  is  not  able  to  put  them  to 
effective  use.  CENTACS  has  recognized  the  need 
for  education  and  training  and  initiated  a  compre¬ 
hensive  program  to  provide  academia  and  industry 
with  necessary  curriculums  and  imaterials  to  meet 
that  need.  Since  this  is  the  topic  of  this  paper, 
it  will  be  described  in  greater  detail  be  lew. 

Policy  and  Objectives 

The  DOD  has  established  Ma  as  the  standard 
programming  language  to  be  used  across  all  defense 
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systems.  CECCM  and  its  parent  Oxtirvinci ,  DARCCM, 
are  also  requiring  tlie  use  of  Ada  as  a  Program 
Design  Language  (POL)  for  Army  systems.  The  Army 
seeks,  further,  to  establish  the  ALS  as  a  comon 
support  environment  to  be  used  across  all  Battle¬ 
field  Automated  Systems  (BAS's).  The  overall 
objective  is  clear:  comon  languge,  cannon  support 
environments,  cannon  methodology  and  cannon 
education/training.  With  software  costs  continuing 
to  grow  at  a:,  alarming  rate,  catvnonal  ity  is  not 
past  desi rouble  -  it  is  essential. 

Aria  Education  and  Training  Initiatives 

CENTALS  activities  in  this  area  have  been  focused 
on  the  separate  needs  of  the  academic  community 
(education)  and  those  of  Industry  and  Government 
(training) .  The  cannon  theme  in  both  arenas  is 
the  timely  development  of  Ada  materials  and  prod¬ 
ucts  winch  con  be  used  to  cultivate  widespread  Ada 
literacy  and  skills. 

Education  Initiatives 

The  "Ada/Ed"  Translator/Interpreter 

When  the  Ada  language  first  began  to  emerge, 
CENTACS  recognized  the  need  for  an  implementation 
that  could  be  used  for  experimental  but,  primarily, 
educational  (thus  Ada/Ed)  purposes.  This  project, 
which  has  been  performed  under  contract  with  the 
Courant  Institute  of  New  York  University,  was 
initiatived  at  a  point  when  the  Ada  language  was 
not  completely  defined  and  has  culminated  in  the 
first  fully  validated  ANSI-Ada  translator. 

Ada/Ed  was  written  in  a  very  high  level  "set" 
language  (called  SETL) .  This  approach  enabled  the 
translator  to  be  implemented  in  roughly  one-fifth 
the  time  that  might  otherwise  have  been  expected. 
However,  rapid  implementation  via  this  approach 
was  achieved  at  the  expense  of  execution  speed 
(Ada/Ed  is  slew)  . 

Ada/Ed  runs  on  a  VAX-11/780  and,  despite  its 
slowness,  has  been  widely  acclaimed  as  a  valuable 
education  tool,  with  a  particularly  friendly'  user 
interface. 

Ada/Ed  has  been  placed  in  the  public  dcmarn 
and  can  be  acquired  from  the  National  Technical 
Information  Service  (NTIS) ,  U.S.  Department  of 
Camerce,  5185  Port  Royal  Road,  Springfield,  VA 
22181,  Phone:  (703)  487-4650,  for  a  nominal 
(reproduction)  fee. 

A  continuation  contract  with  NYU  is  currently 
focused  on  maintenance,  efficiency  improvements 
and  re-validation  through  the  AJPO. 

Initiatives  for  Academia 

If  Ada  is  to  be  truly  successful ,  we  must 
address  the  need  to  educate  member  of  our  future 
workforce  as  they  advance  through  our  academic 
institutions.  CENTACS  recognized  this  need  and 
has  sponsored  a  contract  with  Jersey  City  State 
College  which  has  thus  far  led  to  the  development 


of  two  courses  and  the  establ ishment  of  an  Ada 
Technology  Center. 

The  two  courses  -  one  undergraduate,  one 
graduate  -  address  Ada  philosophy  and  concepts, 
syntax,  semantics  and  provide  ccmpianentary 
exercises  and  hands-on  experience  using  Ada/Ed  or. 
a  VAX-11/780.  The  undergraduate  course  focuses  on 
Ma  fundamentals  while  the  graduate  course  provides 
advanced  topics  such  as  "tasking”  and  "generics". 

The  graduate  course  was  taught  at  Fort  Monmouth 
over  an  eight  week  period  (2  hours,  twice  a  week) 
with  CENTACS  personnel  serving  as  the  evaluators. 

The  undergraduate  course  was  given  at  Jersey  City 
State  College  with  students  majoring  in  computer 
science  serving  as  evaluators.  Both  courses  have 
been  favorably  received  and  suggestions  from  the 
evaluations  have  already  been  incorporated. 

Course  materials  include  lesson  plans,  teachers 
guides,  student  guides,  and  viewgraphs.  Again,  all 
materials  will  be  placed  in  the  public  demain  and 
will  be  accessible  through  the  OTIS. 

An  Ada  Technology  Center  has  also  been 
established  at  Jersey  City  State  College.  It 
currently  includes  a  VAX- 11/780  and  eight  DEC  GIGI 
terminals.  The  center  was  established  to  serve  as 
a  friendly  site  to  government,  industry  and  academia 
personnel  pursuing  Ada  research,  training  or  educa¬ 
tion. 

Future  activity  with  Jersey  City  State  College 
will  include  the  development  of  additional  courses 
and  an  atteirpt  to  automate  the  courses  (via  the 
DEC  “Course  Authoring  System")  so  that  they  can  be 
both  self-paced  and  portable  to  other  sites. 

Training  Initiatives 

Initiatives  for  Government  and  Industry 

In  considering  the  development  of  or.  Ada 
training  program  for  Industry  and  Government, 
CENTACS,  with  strong  contractual  support  frem 
Softech,  Inc. ,  chose  a  very  systematic  approach. 
Three  distinct  data  gathering  activities  were 
initiated  as  a  means  to  formulate  training  require¬ 
ments. 

The  first  involved  the  use  of  Ada  in  the 
redesign  of  selected  portions  of  the  AN/TSQ-73 
and  the  AN/TYC-39  by  Control  Data  Corporation  and 
General  Dynamics,  respectively.  In  the  course  of 
these  "case  studies" ,  Softech  monitors  were  able 
to  identify  the  issues  (language,  environment  and 
methodology)  which  are  of  greatest  concern  (i.e., 
candidates  for  training  oriphasis)  in  approaching 
the  use  of  Ada  on  real  Army  systems. 

The  second  activity  involved  a  survey  of  the 
industry  and  government  workforces  in  an  attempt 
to  identity  and  understand  the  functions  which 
ore  performed  by  personnel  working  on  the  develop¬ 
ment  of  large-scale  anbedded  computer  systems. 

Each  identified  job  category  was  characterized  by 
the  associated  duties  and  the  required  technical 
and  educational  background. 
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Hie  third  activity  involved  a  survey  of 
industrial  training  methods  and  practices.  Here, 
six  large  corporations,  each  with  extensive 
involvement  m  large-scale  systems,  were  queried 
to  determine  the  most  effective  training  approaches 

The  results  of  the  case  studies,  the  workforce 
and  training  methods  surveys  were  analyzed  and  15 
generic  job  categories  (see  figure  1)  were  identi¬ 
fied  with  suggested  course  sequences  within  an 
overall  model  Ada  training  curriculum.  Courses 
in  the  model  Ada  curriculum  can  be  divided  into 
three  basic  categories:  Ada  language,  software 
engineering  methodology  and  Ada  program  support 
environment.  The  courses  (35  in  all)  within  each 
category  are  identified  in  figure  2.  CENT ACS  and 
Softech  are  currently  developing  15  of  these 
courses  as  sutitnarized  in  figure  3. 

In  addition  to  these  ’generic"  Ma  training 
materials,  CENTACS  is  alo  developing  material 
unique  to  the  Ada  Language  System  (ALS) .  Included 
here  ore  a  Users  course,  an  ALS  textbook,  an  ALS 
Administrator  Manual  and  an  ALS  administrator 
course . 

All  of  these  materials,  when  ccrplete,  will 
also  be  placed  in  the  public  domain  and  be 
accessible  through  the  NTIS. 

Future  activities  here  will  include  the 
development  of  additional  courses  within  the 
model  curriculum  and  the  pursuit  of  the  automa¬ 
tion  of  selected  Ada  and  ALS  training  material. 

Summary 


Through  primary'  contracts  with  Softech,  Inc., 

Now  York  University  and  Jersey  City  State  College, 
CENTACS  has  produced  a  great  deal  of  educational 
and  training  material  in  support  of  the  Ada 
language.  While  much  has  been  accomplished,  a 
great  deal  remains  and  the  Army  intends  to  remain 
active  in  this  important  arena  to  help  insure  the 
ultimate  success  of  Ada. 
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ABSTRACT 

■  -y  This  paper  describes  the  U.  S.  Army  Model  Ada 
Training  Curriculum,  developed  by  SofTech,  Inc. 
for  the  U.  S.  Army,  Ft.  Monmouth,  N.J.  The  curric¬ 
ulum  consists  of  individual  modules  which  can  be 
grouped  together  to  form  the  courses  and  training 
plans  that  best  satisfy  the  needs  of  specific 
organizations.  The  paper  describes  the  modules  in 
terms  of  content,  prerequisites,  and  status,  as  of 
the  date  of  this  conference.  Finally  the  paper 
addresses  how  a  manager  might  go  about  using  this 
curriculum  to  satisfy  the  training  needs  of  his 
organization. 

Section  1 
BACKGROUND 

The  U.  S.  Army  Model  Ada  Training  Curriculum 
defines  a  comprehensive  set  of  training  modules , 
or  building  blocks,  which  can  be  connected  in  a 
variety  of  ways  to  form  the  courses  and  training 
programs  that  best  satisfy  a  given  set  of  Ada 
training  needs  (see  Figure  1) . 

It  is  well  recognized  that  software  develop¬ 
ment  does  not  depend  solely  on  a  language,  even 
Ada.  Ada  must  be  used  in  conjunction  with  a  good 
methodology  and  systems  must  be  developed  within 
the  framework  of  a  rich  and  integrated  programming 
environment.  Consequently  the  modules  of  the  U.  S. 
Army  Model  Ada  Training  Curriculum  cover  three 
areas:  the  Ada  language,  methodology  (both  design 
and  coding) ,  and  the  environment.  The  modules 
within  each  of  these  specific  areas  are  listed  in 
Tables  1-3,  along  with  brief  descr iptions . [ 1 ] 
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The  modules  of  the  curriculum  differ  in  one 
or  more  of  the  following  dimensions:  area,  depth, 
and  viewpoint.  Each  of  these  dimensions  is  dis¬ 
cussed  below. 

1 . 1  Area 

Each  module  identifier  starts  with  a  letter. 
This  initial  letter  indicates  the  area  with  which 
the  module  is  to  be  associated.  Modules  beginning 
with  the  letter  L  address  the  Ada  language.  Mod¬ 
ules  beginning  with  the  letter  M  and  E  address 
methodology  and  programming  environment 
respectively. 

1.2  Depth 

Because  each  individual  does  not  require  the 
same  degree  of  knowledge  of  a  specific  area,  mod¬ 
ules  in  the  curriculum  differ  in  terms  of  depth  of 
material  presented.  The  depth  is  indicated  by  the 
first  digit  occurring  in  the  module  identifier.  A 
level-1  module,  indicated  by  the  digit  l,  is  a 
module  having  no  prerequisites  within  the  curric¬ 
ulum.  A  level-1  module  may  have  some  prerequisites 
in  terms  of  general  computer  science  knowledge  not 
related  to  Ada.  For  example  L103,  Introduction  To 
High  Order  Languages,  has  no  prerequisites  within 
the  curriculum.  The  objective  of  L103  is  to  intro¬ 
duce  assembly  language  programmers  to  the  concept 
of  high  order  languages,  not  to  introduce  a  novice 
to  the  world  of  computing.  Consequently  L103  does 
require  experience  in  assembly  language  program¬ 
ming  as  a  prerequisite. 

Level-2  modules,  indicated  by  the  digit  2, 
have  prerequisites  that  can  be  satisfied  by 
level-1  modules,  and  so  on. 

1 . 3  Viewpoint 

Whereas  a  programmer  needs  detailed  instruc¬ 
tions  on  using  the  tools  within  the  programming 
environment,  a  system  administrator  needs  to  know 
what  demands  those  tools  make  on  system  resources. 
The  fact  that  different  individuals  have  different 
views  of  a  specific  subject  matter,  is  addressed 
by  the  curriculum.  As  the  module  level  increases, 
the  viewpoint  changes.  Level-1  modules  basically 
address  managerial  needs.  Level-2  modules  address 
programmer  needs,  and  so  on. 
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Section  2 
CURRENT  STATUS 

Currently  SofTech,  Inc.  is  under  contract  to 
develop  a  selected  subset  of  the  modules.  Module 
development  follows  the  software  engineering  proc¬ 
ess.  A  Preliminary  Design  Review  (PDR)  is  con¬ 
ducted  with  the  government.  Upon  government  ap¬ 
proval  of  the  design,  development  begins.  Upon 
completion  of  development  a  Critical  Design  Review 
(CDR)  takes  place  at  Fort  Monmouth.  Basically  the 
CDR  is  the  first  teaching  of  a  module  and  func¬ 
tions  as  an  acceptance  test.  At  the  conclusion  of 
the  CDR,  government  feedback,  along  with  student 
and  instructors'  suggestions,  is  considered  for 
inclusion  in  the  final  product. 

The  specific  modules  under  development,  their 
length  and  expected  completion  date  are  shown  in 
Table  4. 

Section  3 
PACKAGING 

It  is  important  to  realize  that  one  module 
can  not  satisfy  the  needs  of  an  organization. 
Modules  are  packaged  together  to  create  a  course 


for  a  specific  organization.  When  selecting  a 
course,  the  following  must  be  kept  in  mind. 

3 . 1  Define  the  Viewpoint 

Who  needs  to  be  trained  in  your  organization? 
Managers  and  practitioners?  Once  the  viewpoint  is 
selected,  look  for  the  modules  that  can  be  pack¬ 
aged  together  to  train  that  viewpoint.  Managers 
courses  tend  to  be  shorter  and  more  concept  ori¬ 
ented  than  programmers  courses.  But  do  not  assume 
that  the  managers  courses  are  therefore  superfi¬ 
cial;  in  many  cases  the  emphasis  on  concepts  (as 
opposed  to  details)  makes  the  manager's  courses 
deeper  than  any  practioner's  course. 

3 . 2  Define  the  Level 

The  lower  level  courses  contain  the  concept 
material  required  for  managers.  As  previously 
stated  they  are  prerequisites  for  the  higher  level 
modules.  However  for  software  managers  who  influ¬ 
ence  software  without  actually  writing  any  code, 
or  for  QA  personnel,  consultants,  analysts,  etc., 
the  higher  levels  are  also  appropriate. 

3 . 3  Identify  the  Main  Course 

After  having  satisfied  the  prerequisites,  an 
entry  level  programmer  probably  only  needs  L202  to 
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Table  1.  Environment  Modules 


NO. 

TITLE 

DESCRIPTION 

DURATION 

APSE  Concepts  Cor 

Technical  Managers 

broad  overview  of  APSE  emphasizing 
how  it  supports  s/w  life  cycle 

1  day 

APSE  Overview  for 

Programmers 

broad  overview  of  APSE  for  software 
developers 

1/2  day 

E10  3 

Basic  APSE  Operation 

introduction  to  APSE  concepts, 
basic  editing,  etc.,  for  people  who 
will  not  be  real  users 

1/2  day 

E201 

User*s  Introduction  to 
the  APSE 

basic  use  of  the  APSE  database,  file 
system,  command  language;  tool 
overview 

3  days 

E301 

Command  Language 

command  language,  subst itutors ,  I/O 
redirections 

1  day 

Program  Development 

Compiler,  linker,  exporter,  loader 

E303 

Database 

files,  directories,  attributes, 
associations,  access  control,  node 
sharing,  program  libraries,  etc. 

2  days 

E304 

Debugging 

debugger,  timing  analyzer,  frequency 
analyzer 

1  1/2  days 

E305 

Assembling  and  Importing 

assembly  language,  importer 

1/2  day 

E306 

Configuration  Management 
and  Program  Management 

tools  to  support  CM  and  PM,  example 
tools  one  might  build 

3  days 

E401 

How  to  Add  Tools 

programming  with  the  command 
language,  KAPSE  tool  interfaces, 
examples  of  useful  tools 

2  days 

E402 

System  Administrator's 

Course 

user  authorization  and  protection, 
installation,  backup,  system  support 

3  days 

Table  2.  Ada  Language  Modules 


NO. 

TITLE 

DESCRIPTION 

DURATION 

L101 

Ada  Orientation  for 

Managers 

overview  of  development  and 
features  of  Ada 

1/2  day 

L102 

Ada  Technical  Overview 

overview  of  language-introduction 
to  language  features  in  more 
depth  than  above 

1  day 

L103 

Introduction  to  High 

Order  Languages 

key  HOL  concepts  for  assembly 
language  programmers 

1  day 

L104 

Beginning  Programming 

introduction  to  computer 
programming  in  an  Ada  context 

4  weeks 

L201 

Ada  for  Software 

Managers 

__ 

use  of  Ada  for  good  systems  design; 
packages,  types,  generics, 
portability  features,  etc. 

3  days 

L202 

Basic  Ada  Programming 

essentially  the  Pascal  subset 

1  week 

L301 

Using  the  Ada  Language 
Reference  Manual 

how  to  use  the  alarm  effectively 
as  a  reference 

2  days 

Table  2.  Ada  Language  Modules  (continued) 


NO. 

TITLE 

DESCRIPTION 

DURATION 

L302 

Use  of  Ada  for 

Requirements 

Ada  as  a  requirements  definition 
language 

2  days 

L303 

Real  Time  Concepts 

real  time  design  concepts  for 
technical  managers 

1  day 

L304 

Ada  Reader's  Course 

reading  an  Ada  design  or  program 
for  its  key  points  and  overall 
structure 

1  day 

L305 

Advanced  Ada  Topics 

packages,  access  types,  private 
types,  discriminated  records, 
generics,  basic  tasking,  basic 
algorithms 

1  week 

L401 

Real  Time  Systems 
in  Ada 

everything  about  tasking,  external 
interfaces,  low-level  features 

1  week 

L500 

Specialty  Courses 

numerical  analysis,  hardware 
diagnostics,  man/machine  interface 
database  management,  etc. 

varying 

Table  3.  Methodology  Modules 


NO. 

TITLE 

DESCRIPTION 

DURATION 

M10 1 

Software  Engineering 
for  Managers 

software  life-cycle,  top-down 
concepts,  documentation,  testing 

1  day 

M102 

Introduction  to  Software 
Engineering 

life-cycle,  top-down  concepts, 
overview  of  various  methodologies 

2  days 

M201 

Software  Engineering 
Methodologies 

thorough  coverage  of  major 
methodologies 

1  week 

M202 

Overview  of  a  Specific 
Methodology 

overview  of  an  organization's 
selected  life-cycle  methodology 

1/2  day 

M30 1 

Requirements  Methodology 

requirements  definition  techniques 
and  methodology 

1  week 

M302 

Design  Methodology 

how  to  do  design,  with  required 

4  days 
methodology 

M303 

Coding  Methodology 

structured  programming,  coding 
standards,  programming  style,  etc. 

2  days 

M304 

Software  Review 

Methodology 

Walkthroughs,  code  reading 

1  day 

M401 

Introducing  Ada  to  Your 
Organization 

how  to  use  the  recommended 
curriculum  to  meet  specific  needs 

1  day 

M402 

Psychological  Aspects 
of  Retraining 

techniques  for  overcoming  resistance 
to  change 

1  day 
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Table  4.  Module  Completion  Dates 


MODULE/COURSE 

L101  Ada  Orientation  for  Managers 

L102  Ada  Technical  Overview 

L103  Introduction  to  High  Order  Languages 

L201  Ada  For  Software  Managers 

L202  Basic  Ada  Programming 

L301  Using  The  Ada  Language  Reference  Manual 

L302  Use  of  Ada  for  Requirements 

L303  Realtime  Concepts 

L304  Ada  Reader's  Course 

L305  Advanced  Ada  Types 

L401  Realtime  Systems  In  Ada 

Ml 01  Software  Engineering  For  Managers 

M102  Introduction  To  Software  Engineering 

M201  Software  Engineering  Methodologies 

M303  Coding  Methodology 

£300*  ALS  Users  Course 

E402  ALS  Administrator's  Course 

*E300  encompasses  the  majority  of  the  E  modules. 


LENGTH  (IN  DAYS)  AVAILABLE  TO  TEACH 


1 

Now 
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Now 
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Now 
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Now 

10 

Now 
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April  84 
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April  84 
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March  84 

10 

Now 

10 

May  84 

1 

Now 
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Now 
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Now 

2 

April  84 

10 

April  84 

3 

April  84 

become  productive.  A  designer,  on  the  other  hand 
needs  to  progress  on  to  L305,  and  the  real  time 
system  programmer/analyst/designer  should  take 
L401. 


For  top  level  managers,  L101  is  appropriate. 
For  senior  QA  personnel,  program  monitors,  soft¬ 
ware  managers,  etc.  L201  is  appropriate. 

3.4  Search  for  Related  Courses 


A  language  course  without  parallel  courses  in 
methodology  and  environment  is  like  a  car  without 
an  engine.  The  only  reason  that  language  courses 
appear  in  isolation  is  because  different  organiza¬ 
tions  use  different  methodologies  and  different 
environments.  It  is  also  possible  that  an  organi¬ 
zation  may  be  proficient  in  software  engineering 
and  only  need  training  in  a  specific  language. 


The  point  is  that  once  a  main  course 
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look  for  r« 
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indivisible. 

the 
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and 

• 

L102 

and 

• 

L202 

and 

• 

L305 

and 

is  iden- 
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Additionally  each  pair  listed  may  be  taught 
sequentially  or  in  parallel. 

Ideally  each  of  the  pairs  should  be  comple¬ 
mented  by  a  third  course  from  the  environment. 
Currently  environment  courses  are  fewer  in  number. 
As  a  consequence  L202  is  usually  supplemented  with 
a  brief  introduction  to  the  basic  tools  needed  to 
develop  homework  assignments. 

3.5  Do  Not  Forget  the  Prerequisites 

One  common  mistake  is  to  focus  on  the  modules 
that  include  exercises  to  be  coded  and  executed, 
such  as  L202  and  L305.  These  two  modules  have 
prerequisites. 

Another  common  mistake  is  to  select  the 
"meaty"  modules,  such  as  L201  and  M201.  Unless  it 
is  guaranteed  that  the  students  have  the  prerequi¬ 
sites,  the  students  should  take  a  few  low  level 
modules  first. 

3.6  Consider  an  Acceleration 


In  many  cases  an  organization  is  faced  with 
stringent  time  constraints.  In  these  cases  several 
of  the  modules  in  the  low  level  may  be  compressed, 
with  additional  explanations  and/or  exercises 
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supplied,  where  appropriate,  in  the  higher  level 
modules.  As  a  general  rule  however,  acceleration 
is  not  a  recommended  practice. 

3.7  A  Couple  of  Exceptions 

The  curriculum  has  a  few  exceptions.  For 
example  L301,  Reading  the  Reference  Manual,  can  be 
viewed  as  a  stand  alone  course.  A  solid  under¬ 
standing  of  Ada  is  really  the  only  prerequisite 
for  this  course.  How  that  understanding  has  been 
acquired  is  not  relevant. 

The  prerequisite  for  M201  is  really  a  good 
solid  understanding  of  software  engineering. 

Again,  how  this  has  been  acquired  is  not  relevant. 

M303  can  be  taught  after  L202,  during  L202, 
or  in  parallel  with  L202. 


Section  4 

ISSUES  NOT  ADDRESSED  BY  THE  CURRICULUM 

The  curriculum  does  define  a  set  of  prec¬ 
edences  among  the  modules,  as  shown  in  Figure  1. 
The  intended  interpretation  of  Figure  1  is  as 
follows:  inputs  to  a  given  module  define  the  pre¬ 
requisites  for  that  module.  The  Figure  does  not 
recommend  paths  through  the  curriculum.  The  line 
from  L202  to  L305  means  that  if  there  is  interest 
in  L305,  L305  should  be  taken  after  L202.  The  line 
does  not  mean  that  after  taking  L202  an  individual 
must  procede  to  L305. 

The  curriculum  does  not  state  how  these  mod¬ 
ules  are  to  be  packaged  into  a  course.  There  are 
distinct  courses  that  belong  together.  However 
each  organization  has  its  own  needs  and  therefore 
will  create  its  own  "packaging"  of  modules  into  a 
course. 

The  curriculum  does  not  state  how  much  train¬ 
ing  is  required  by  each  individual  within  an 
organization  or  the  total  set  of  skills  to  be 
taught  within  an  organization. 

The  curriculum  does  not  address  specific 
contents  of  modules  that  are  particularly  sensi¬ 
tive  to  a  specific  organization,  e.g.,  M301,  M302, 
M303,  and  M304.  These  modules  are  defined  in  gen¬ 
eral  outline  only  and  can  be  adapted  to  any  meth¬ 
odology.  The  same  holds  true  for  some  environment 
modules. 


Section  5 

DEVELOPING  AN  ADA  TRAINING  PROGRAM 

The  curriculum  is  not  the  starting  point  for 
a  complete  training  program.  The  real  starting 
point  for  an  organization  in  developing  a  training 
program  is  to  analyze  the  training  requirements  in 
terms  of 


•  number  of  levels  to  be  trained 

•  number  of  individuals  at  each  level 

•  level  of  expertise  required  for  each 

individual 

•  current  skill  level 

•  customization  of  course  materials 

•  cost  and  time  constraints 

•  supplemental  training  materials  desired 

Once  these  issues  have  been  analyzed,  courses 
must  be  scheduled.  Generally  it  is  effective  to 
train  managers  before  staff,  designers  before 
implementors. [2]  Management  commitment  to  the 
concepts  of  Ada  is  essential  to  its  acceptance  by 
employees.  Designers  can  be  designing  while  train¬ 
ing  the  implementors  is  taking  place.  The  imple¬ 
mentors  have  the  support  of  the  designers  and  have 
the  motivational  level  required. 


Section  6 
SUMMARY 

Transition  to  Ada  is  a  non- trivial  process 
requiring  a  great  deal  of  thought.  Many  individ¬ 
uals  may  find  they  are  transitioning  to  Ada  with¬ 
out  really  realizing  it.  The  potential  for  the 
U.  S.  Army  Model  Ada  Training  Curriculum  to  aid  in 
this  transition  is  unlimited. 
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ABSTRACT 

''Three  characteristics  of  large  software 
projects  and  five  basic  configuration  management 
capabilities  are  identified.  The  design  of  the 
Ada  Language  System  (ALS)  is  then  described  in 
terms  of  these  Dasic  capabilities.  The  ALS  is  a 
computer  programming  support  environment  for  Ada.. 


Section  1 
INTRODUCTION 

Tne  emergence  of  software  engineering  as  a 
distinct  discipline  has  fostered  examination  of 
the  methods  used  to  program  computers.  This,  in 
turn,  has  led  to  the  development  of  a  number  of 
unified  environments  to  aid  programmers  and  im¬ 
prove  their  productivity.  Many  of  these  envi¬ 
ronments  have  viewed  the  programmer  as  an  auton- 
mous  individual  producing  self-contained  soft¬ 
ware.  However,  in  most  industrial,  military,  and 
commercial  applications,  it  is  much  more  reason¬ 
able  to  view  the  programmer  as  a  member  of  a 
team  producing  software  that  must  be  precisely 
matched  to  the  software  produced  by  other 
members  of  the  team.  This  fact  has  been  ac¬ 
knowledged  in  the  Ada  programming  language, 
where  emphasis  has  been  placed  on  the  production 
of  an  entire  coordinated  software  system  rather 
than  a  collection  of  loosely  coordinated  modules. 
The  Ada  Language  System  (ALS)  is  a  programming 
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environment  that  supports  the  development  of 
large  systems  in  Ada.  The  ALS  provides  the 
underlying  facilities  necessary  to  coordinate 
programmers  working  in  teams.  The  ALS  was 
developed  by  SofTech,  Inc.  for  the  U.S.  Army 
using  the  Stoneman  Requirements  [BUXT]  as  a 
guideline. 

This  paper  first  identifies  three  major 
aspects  of  large  team-oriented  projects  which 
differentiates  them  from  small  one-man  efforts. 
The  ALS  features  which  support  such  projects  are 
described. 


Section  2 

CHARACTERISTICS  OF  LARGE  SOFTWARE  PROJECTS 

Large  team-oriented  software  efforts  have 
three  characteristics  which  differentiate  them 
from  small  individual-oriented  projects. 

•  Large  projects  are  usually  developing  a 
family  of  similar  programs  rather  than 
a  single  program. 

•  Configuration  management  is  of  critical 
importance. 

•  Close  coordination  of  many  programmers 
is  necessary. 

Although  the  Discussion  of  these  issues  is 
separated,  they  are  all  heavily  interrelated. 


2.1  Families  of  Programs 

Software  is  aptly  named.  It  is  the  soft 
part  of  any  computer  system;  it  is  the  most 
malleable,  easily  changed  part  of  the  system;  it 
is  the  part  that  is  expected  to  adapt  to 
changing  requirements  and  changing  hardware.  In 
fact,  the  software  is  often  specifically  design¬ 
ed  to  be  adapted  to  differing  situations.  It  is 
the  part  that  can  be  altered  most  rapidly  at  the 
least  expense,  provided  changes  are  made  in  an 
orderly  fashion.  Even  a  perfect  piece  of  soft¬ 
ware  with  no  errors  will  still  tend  to  accum¬ 
ulate  changes  for  the  following  reasons: 
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•  the  requirements  of  the  original 
application  have  changed, 

•  the  hardware  configuration  has  changed, 

or 

•  the  software  is  to  be  incorporated  into 
a  new  application. 

A  change  in  the  original  requirements  can  result 
from  a  change  in  the  external  world  or  the  iden¬ 
tification  of  a  shortcoming  in  the  requirements 
as  originally  conceived.  Hardware  changes  occur 
for  many  reasons:  the  correction  of  hardware 
problems,  improved  capacity  and  performance, 
reduced  cost,  production  and  supply  proolems, 
etc.  Software  is  often  designed  at  the  outset 
to  run  on  a  variety  of  hardware  to  accommodate 
various  sized  applications.  In  general,  each 
hardware  configuration  requires  a  different  copy 
of  the  software  even  though  the  difference  in 
the  software  might  be  as  minor  as  the  adjustment 
of  a  compile-time  constant.  Finally,  bits  and 
pieces  of  software  tend  to  migrate  from  one 
application  to  another,  from  one  computer  to 
another,  changing  in  some  way  each  time  a  migra¬ 
tion  occurs. 

Every  change  to  a  software  component  that 
can  affect  its  operation  must  be  regarded  as 
creating  a  new  component  with  different  prop¬ 
erties.  It  is  a  serious  error  to  assume  that 
the  significance  of  a  change  is  related  to  the 
amount  of  source  text  altered.  A  single  char¬ 
acter  alteration  can  be  just  as  devastating  to 
the  final  operation  of  a  system  as  a  10,000 
character  alteration.  However,  programs  differ¬ 
ing  textualiy  by  only  a  small  amount  are  related 
and  should  be  treated  as  such.  It  is  important 
to  maintain  the  identity  of  such  famiiies  of 
programs  because  an  error  in  one  member  of  the 
family  is  likely  to  exist  in  many  members  of  the 
family.  Members  of  a  family  may  also  be  tex- 
tually  unrelated;  e.g.,  they  may  be  coded  in 
different  programming  languages.  However,  if 
they  are  functionally  similar,  they  may  share 
errors.  A  program  family  may  be  loosely  defined 
as  those  modules  which  have  evolved  from  a 
common  source  text.  The  source  text  is  often, 
but  not  always,  the  compilable  text  of  a  pro¬ 
gram;  it  may  be  the  definition  of  an  algorithm 
or  pseudo-code.  In  general,  the  members  of  a 
program  family  will  all  perform  similar  func¬ 
tions  lCARG]  [TICHj.  The  notion  of  a  program 
family  is  supported  in  the  ALS  by  a  database 
feature  called  a  "variation." 

Program  families  inevitably  arise  wherever 
there  must  be  ongoing  software  support  for  mul¬ 
tiple  fielo  installations.  Unless  the  field 
installations  are  all  identical  and  never 
change,  there  will  be  differing  software  for  the 
various  hardware  configurations.  Given  the  rate 
of  change  in  the  computer  industry ,  it  is  incon¬ 
ceivable  that  any  product  would  not  undergo 
design  changes  for  cost  reduction  alone.  Many 
classes  of  products  can  be  expected  to  undergo 
continuous  field  upgrades  which  require  software 
alteration.  The  ability  to  control  families  of 


software  may  reduce  the  need  to  apply  field 
upgrades  to  bring  hardware  into  conformance  with 
a  standard.  With  strong  support  for  program 
families,  the  software  could  be  custom-generated 
to  adapt  to  each  hardware  configuration. 


2.2  Configuration  Management 

Configuration  Management  (CM)  is  the  "con¬ 
sistent  labeling,  tracking,  and  change  control 

of  the  ...  elements  of  a  system"  [BERS].  There 
are  a  number  of  economic  and  technical  forces 
which  mandate  increasing  emphasis  on  CM  for 
industrial  grade  software.  Among  these  are: 

•  reliability  requirements, 

a  complexity,  and 

a  ongoing  support  requirements. 

A  growing  number  of  computer  applications  have 
exceedingly  high  reliability  requirements.  In 
such  applications  as  aircraft  and  spacecraft 
control,  automotive  control,  weapons  control, 
and  medical  systems,  software  failure  can  result 
in  personal  injury  or  loss  of  life.  In  such 
cases,  strong  CM  is  necessary  to  ensure  that  all 
operational  software  has  been  fully  tested  and 
that  unproven  alterations  do  not  find  their  way 
into  delivered  systems.  In  very  complex  systems, 
the  change  control  aspect  of  CM  is  used  during 
development  simply  to  ensure  that  the  elements 
of  a  system  are  kept  stable  enough  over  time  to 
be  successfully  integrated.  In  applications 
where  software  corrections  and  improvements  are 
to  be  provided  on  an  ongoing  basis  to  remote 
field  locations,  CM  is  necessary  to  assure  that 
delivered  software  is  appropriate  to  the  hard¬ 
ware  configuration  at  that  site. 

CM  is  usually  achieved  by  the  creation  of 
one  or  more  "baseline"  copies  of  the  software. 
Each  baseline  has  some  official  status.  There 
can  be  working  baselines  updated  frequently  by 
the  programming  team,  frozen  baselines  pre¬ 
serving  exact  copies  of  software  delivered  to 
field  locations,  etc.  CM  is  obtained  by 
management  review  of  proposed  changes  to 
baselines  and  monitoring  and  recording  of  actual 
changes.  In  order  to  perform  CM,  one  must  be 
able  to: 

•  absolutely  identify  the  elements  of  a 
baseline  at  any  point  in  time, 

•  absolutely  identify  the  elements  of  a 
system  placed  in  revenue  service, 

•  account  for  and  control  all  changes  to 
a  baseline, 

•  recreate  exactly  a  system  that  existed 
in  the  past  or  exists  at  a  field  site, 
and 

•  control  the  corresDondence  between 
tested  and  delivered  systems. 
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ru.-i!  though  companies  ana  projects  have 
diverse  methods  tor  performing  CM,  there  are 
five  capabilities  oasic  to  all  Cm.  Tnese  are: 

•  absolute  identification, 

■  change  identification, 

•  change  tracking, 

•  inventory  control,  and 

•  access  control. 

Absolute  identification  is  the  ability  to 
reliably  associate  a  name  with  a  component  of  a 
system,  usually  stored  in  a  file.  When  a 
component  changes,  no  matter  how  small  the 
change,  a  new  component  with  a  different  name  is 
created.  Change  identification  is  the  ability 
to  readily  recognize  wnen  a  change  has 
occurred.  Change  tracking  is  the  ability  to 
record  and  review  the  sequence  of  changes  to  a 
component.  Inventory  contro1  is  the  ability  to 
record  exactly  wnat  components  constitute  a 
system  at  any  point  in  time.  finally,  access 
control  is  the  ability  to  guarantee  that  all 
changes  to  a  baseline  are  authorized  and 
documented. 

A  capability  fundamental  to  all  CM  is  ab¬ 
solute  identification  of  software  components. 
Most  conventional  file  systems  fail  to  provide 
the  basic  underlying  support  for  absolute  iden¬ 
tification.  Typically,  the  source  code  for  a 
component,  say  a  sine  routine,  is  stored  in  a 
file  that  might  be  named  SINE. SRC.  Another  file, 
SINE. OBJ,  usually  holds  the  object  code. 
SINE. OBJ  miyht  oe  bound  into  any  number  of 
executable  images  with  unrelated  names.  CM 
problems  occur  when  a  change  is  made.  Typi¬ 
cally,  the  change  is  introduced  by  in-piace 
editing  of  the  source  file.  The  name  of  the 
source  file  remains  unchanged  after  the 
alteration.  A  revi-  sion  history  may  be  part  of 
the  source  file,  but  the  person  inserting  the 
change  may  not  possess  enough  self-oiscipline  to 
note  the  change,  par-  ticularly  when  the  change 
is  viewed  as  minor.  The  altered  source  is 
subsequently  recompiled  with  the  new  object 
replacing  SINE. OBJ.  Since  the  file  name  is  not 
altered,  the  change  is  invisible  to  programmers 
incorporating  SINE. OBJ  in  their  systems. 

If  the  change  engenders  an  unexpected  prob¬ 
lem,  ioentification  of  the  problem  may  be  very 
time-consuming.  In  general,  recompilation  from 
source  followed  by  file  comparison  is  necessary 
to  determine  if  a  change  in  SINE. SRC  was  ever 
applied  to  SINE. OBJ.  Determining  if  a  given 
system  has  the  new  or  old  version  of  SINE. OBJ 
involves  keeping  explicit  recorus  of  when  the 
change  to  SINE  was  applied  and  when  the  system 
in  question  was  last  rebuilt.  Such  recoros  are 
seluom  kept.  Partial  rebuilds  of  systems  com¬ 
plicate  the  situation  even  further.  Very  often 


it  is  easier  to  correct  the  present  system  than 
reconstruct  a  clear  historical  picture  of  what 
caused  the  problem.  If  an  erroneous  chanae 
finds  its  way  into  many  systems,  there  can  be 
many  parallel  efforts  to  identify  and  correct 
the  same  error. 

A  major  part  of  this  problem  can  be  alle¬ 
viated  by  incorporating  a  revision  number  in 
file  names.  Every  time  a  file  is  changed,  the 
revision  number  is  incremented.  Identification 
of  changes  is  then  readily  accomplished  by  re¬ 
cording  the  names  of  files  built  into  a  system. 
The  differences  between  two  builds  of  a  system 
can  then  be  quickly  identified  by  comparing  the 
revision  numbers  of  the  components.  Such  visi¬ 
bility  of  changes  is  fundamental  to  the  notion 
of  absolute  identification.  Every  change  or 
closely  related  group  of  changes  must  be  viewed 
as  creating  a  new  object  with  a  distinct  name. 
In  short,  the  name  must  identify  the  object 
abso-  lutely.  (A  single  object  may  have  several 
names,  but  one  name  must  refer  to  a  unique 
object  throughout  the  lifetime  of  the  name.) 

A  revision  numbering  capability  supplies,  at 
one  stroke,  both  change  identification  and 
tracking  mechanisms.  As  long  as  a  new  revision 
is  created  every  time  a  change  is  made  in  a 
baseline,  changes  are  easily  identified  by  the 
high  visibility  of  new  file  revisions.  The 
numbered  sequence  of  revisions  for  each  file 
provides  a  change  tracking  mechanism  upon  which 
tracking  mechanisms  for  entire  baselines  can  be 
readily  constructed. 

Even  with  revision  numbers,  problems  arise 
in  absolutely  identifying  components  when  names 
have  been  changeo.  Component  names  shouio  be 
highly  mnemonic.  But  it  is  desirable  to  allow 
mnemonic  names  to  be  changed  sc  they  stay 
mnemonic  as  software  development  progresses. 
This  broaches  the  possibility  of  renaming  or 
deleting  a  file  and  then  creating  another  file 


with  trie 

old  name.  This 

can 

result 

in  two 

distinct 

components  having 

the 

sane 

name  and 

revision 

number.  To  avoid 

any 

possibility  of 

confusion 

,  it  is  necessary 

to  h 

ave  a 

secondary 

naming  mechanism  where  renaming  and  reuse  of 
names  is  not  possible.  In  the  AlS,  these 
secondary  names  are  called  unique  identifiers. 
The  mnemonic  quality  of  unique  identifiers  is 
sacrificed  for  the  uniqueness  property.  To 
absolutely  identify  a  component,  it  is  OesiraDle 
to  record  botn  the  mnemonic  name  and  the  unique 
identifier.  The  mnemonic  name,  while  not 
absolutely  necessary,  helps  numan  users.  The 
unique  identifier  is  used  mostly  by  configura¬ 
tion  control  tools,  to  avoid  the  ambiguity 
which  coulo  otherwise  arise  if  mnemonic  names 
were  usee  Lu  compare  configurations. 

Inventory  control  is  the  ability  to  create 
and  store  a  complete  list  of  all  the  components 
of  a  baseline  at  some  point  in  time.  Saved 
inventory  lists  can  be  subsequently  compared  to 
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determine  trie  changes  in  a  baseline  over  some 
interval,  or  find  the  differences  between  an 
installed  system  ana  tne  current  baseline. 

Access  control  is  the  aDility  to  guarantee 
that  no  undocumented  or  unauthorized  changes 
fine  tneir  way  into  a  baseline.  The  term  can  be 
more  broadly  interpretea  to  encompass 
examination  as  well  as  modification  of 
baselines.  Of  course,  no  guarantee  can  oe 
absolute.  Most  computer  systems  can  be 
penetrated  by  sufficiently  clever  ana  malicious 
users.  In  addition,  hardware  or  software 
failure  can  always  compromise  access  control. 
It  is  assumed,  here,  that  ALS  users  are  friendly 
ana  tne  hardware  and  software  are  sufficiently 
reliable. 

The  proolem  of  supporting  many  installations 
with  siigntly  differing  configurations  requires 
Cm  fur  families  of  programs.  The  inability  to 
do  this  effectively  usually  results  in  software 
which  must  dynamically  reconfigure  itself  or 
wnicn  must  Oe  completely  rebuilt  at  each  field 
site.  CM  mechanisms  must  be  able  to  deal  with 
cunuitional  compilation  or  macro  expansion 
techniques  used  to  generate  family  members.  In 
tne  ALS,  revisions  ana  derivations  combine  with 
variations  to  support  CM  for  families  of 
prugrains. 


2.3  Coordination  of  Programmers 

In  multi-person  projects,  the  effective  co¬ 
ordination  of  programmers  is  vital.  Lack  of  co¬ 
ordination  results  in  costly  redesign  ana  retro¬ 
fits  curing  system  integration.  In  complex  pro¬ 
jects,  the  lack  of  adequate  coordination  can 
jeopardize  tne  successful  conclusion  of  the  pro¬ 
ject.  An  official  working  copy  or  baseline  of 
the  software  is  usually  used  to  coordinate  the 
er  forts  of  tne  programmers.  There  is  a  spectrum 
of  scenarios  for  using  such  a  baseline.  At  the 
ends  of  trie  spectrum  are: 

•  the  total  sharing  scenario,  and 

•  tne  private  copy  scenario. 

under  total  sharing,  all  incremental  changes  are 
immediately  applied  to  the  working  baseline. 
Tne  system  is  periodically  rebuilt  from  the 
working  baseline.  Such  a  rebuild  or  relink 
usually  occurs  frequently,  on  the  order  of  once 
or  twice  a  day.  Under  the  private  copy  sce¬ 
nario,  each  programmer  has  his  own  copy  of  the 
baseline  which  he  can  modify  or  rebuild  at  will. 

Toe  problem  with  sharing  is  that  programmers 
interfere  with  each  other,  each  making  changes 
that  affect  the  other.  Much  time  is  lost  keep¬ 
ing  up  with  alterations  made  by  other  program¬ 
mers.  Changes  tend  to  proliferate,  one  change 
engendering  others  which  engender  still  more 
Changes.  T tie  rate  of  change  and  lack  of  testing 
of  changes  seriously  reduces  the  chances  of  ob¬ 
taining  a  system  that  works  correctly.  Sharing 


allows  for  little  programmer  freedom  or  the 
opportunity  to  apply  changes  experimentally. 
Even  in  a  two-programmer  team,  total  sharing  may 
be  unworkable. 

The  private  copy  scenario  solves  the  prob¬ 
lems  of  sharing,  but  does  not  provide  any  co¬ 
ordination.  With  private  copies  of  the  base¬ 
line,  each  programmer  works  independently.  The 
longer  a  programmer  works  in  his  private  area, 
the  greater  is  the  chance  that  his  software 
diverges  from,  software  developed  by  others.  On 
the  other  hand,  the  programmer  has  total  freedom 
to  make  changes,  even  to  components  which  are 
the  purview  of  others.  A  programmer  working 
with  an  isolated  copy  of  the  system  does  not 
benefit  from  improvements  introduced  by  other 
team  members. 

In  practice,  some  combination  of  the  two 
scenarios  is  used  to  prevent  the  divergence  of 
the  software.  Typically,  this  involves  the  use 
of  private  work  areas  for  incremental  devel¬ 
opment.  When  an  element  is  completed  and 
tested,  it  is  then  integrated  with  the  official 
baseline.  The  integration  is  very  often 
performed  in  a  private  area  and  the  new  system 
tested  before  it  is  placed  in  the  project 
baseline.  In  addition,  there  are  often 
administrative  proceoures  for  controlling 
baseline  changes  and  for  preventing  changes  to 
components  one  is  not  authorized  to  change.  The 
ALS  provides  a  general  sharing  mechanism  as  well 
as  conventional  copying  to  facilitate  almost  any 
scenario  for  programmer  coordination.  In  addi¬ 
tion,  the  Program  Library  services  of  the  AlS 
gives  programmers  a  totally  isolateo  work  area 
for  Duilding  and  modifying  systems  starting  from 
a  baseline  copy. 

Although  the  examples  in  this  paper  are  con¬ 
fined  to  the  source  and  object  forms  of  computer 
programs,  the  discussion  is  equally  valic  with  a 
more  comprehensive  interpretation  of  the  word 
"software."  The  same  problems  occur  with  all 
types  of  documentation,  e.g.  requirements  spe¬ 
cifications,  design  specifications,  user  refer¬ 
ence  manuals,  tutorial  materials,  etc.  All  of 
these  should  be  included  under  the  umbrella  of 
the  term  "software."  Similarly,  although  the 
discussion  is  illustrated  by  examples  of  soft¬ 
ware  in  the  development  phase,  all  arguments 
apply  equally  well  to  the  maintenance  phase  of 
the  software  life-cycle.  Indeed,  there  is  no 
qualitative  difference  between  the  development 
and  maintenance  phases  in  relation  to  the  issues 
treated  here. 


Section  3 
ALS  CAPABILITIES 

This  section  describes  the  features  of  the 
ALS  specifically  designed  to  support  large-scale 
programming  projects.  The  user's  view  of  the 
Al  S  database  is  presented  in  some  detail.  The 
use  of  these  capabilities  as  they  relate  to 
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Figure  A.  Directories  and  Revision  Sets 


program  families,  Cm,  and  programmer 
coordination  is  treated  in  trie  next  section. 
Information  on  AiS  features  not  related  to  CM 
can  up  founu  in  [  WOLF  J  anti  [THAlj. 


3.1  Nodes 

The  AlS  provides  users  with  a  database  capa¬ 
bility  that  can  be  viewed  as  either  a  sophis¬ 
ticated  file  system  or  a  rudimentary  database 
management  system.  Tne  database  is  a  collection 
of  objects  called  nodes.  There  are  three 
varieties  of  nudes: 

•  files, 

t  directories,  and 

•  variation  headers. 

Files  correspond  to  the  usual  notion  of  a  named 
data  collection.  Directories  ana  variation 
header  nodes  are  used  to  create  groupings  of 
oooes.  All  nodes  in  the  database  p assess  de¬ 
scriptors  called  attributes  and  associations.  An 
attribute  describes  the  node  which  possesses  it. 
Associations  establish  relationships  between 
nudes  in  addition  to  the  relationships  estab¬ 
lished  by  virtue  of  the  groupings  under  direc¬ 
tories  ana  variation  headers. 


3.2  Node  Naming  and  Structuring 

Hierarchical  data  structures  are  built  by 
using  directories  to  group  nodes.  Directories 
are  u=ed  to  group  any  combination  of  files,  var¬ 


iation  headers,  and  other  directories.  Figure  A 
gives  an  example.  Every  AlS  has  exactly  one 
connected  file  structure  with  one  root  directory. 
(Strictly  speaking,  the  root  node  is  anonymous; 
however,  it  can  be  referenced  with  the  name 
Trie  root  node  of  our  example  possess  a  single 
node  named  "math_pac".  The  reader  is  free  to 
think  of  nooe  names  as  being  properties  of 
either  the  node  or  the  link  to  the  node.  How¬ 
ever,  because  of  node  sharing,  a  single  node  may 
acquire  aliases.  Thus,  it  is  more  accurate  to 
think  of  the  names  as  properties  of  the  links. 
Hutting  it  another  way,  the  name  resides  in  the 
parent  directory,  not  in  the  node  itself.  To 
avoid  any  ambiguity,  the  diagrams  snow  node 
names  on  the  links.  In  the  example,  "math_pac” 
is  the  child  (or  offspring)  of  which  is  the 
parent  of  "math_pac".  A  parent  node  is  said  to 
contain  its  offspring. 

The  "math_pac"  directory  has  three  off¬ 
spring,  the  directory  "source"  and  the  files 
"documentation"  and  "tests".  "Source"  in  turn, 
has  five  offspring:  the  files  "sin",  "cos", 
"tayior",  "exp",  ana  "factorial".  Directories 
are  shown  as  ellipses;  and  tiles  are  shown  as 
squares.  Just  as  in  Ada,  the  identity  of  an 
object  depends  upon  its  position  in  the  whole 
structure.  The  full  name  of  an  object  is  known 
as  the  pathname  and  is  constructed  by  tracing 
the  path  to  the  object  from  the  root  ana  naming 
the  links  traversed  along  that  path.  The 
pathname  of  math_pac  is  ".math_pac".  The  name 
of  the  factorial  subprogram  is  ",math_pac 
.source. factorial" .  Several  pathnames  are  shown 
in  Figure  A.  Users  are  encouraged  to  view  the 
data  structure  as  a  tree;  however,  due  to 
sharing  of  nodes,  the  structure  is  not  strictly 
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.<  tret.-,  it  is  a  directed  acyclic  graph.  The  ALS 
excludes  cycles  from  the  structure.  In  other 
dares  a  directory  may  not  contain  a  subtree  that 
contains  that  same  directory. 


3.3  Revision  Sets 

Cvery  fire  in  tne  AlS  Database  is,  in 
actuality,  a  member  ot  a  revision  set.  The 
revision  set  tracks  the  changes  made  to  a  file 
over  time,  each  member  of  a  revision  set  is  a 
snapshot  ot  tne  file  as  it  existed  at  some  point 
in  time.  The  members,  called  revisions,  are 
.irut-reo  in  chronological  sequence  and  are  auto¬ 
matically  numtiereu  in  oruer  starting  from  one. 
Tne  most  recent  revision  supersedes  all  previous 
revisions.  Altnough  a  revision  is  most  often  a 
modified  form  of  cne  previous  revision,  this 
relationship  is  not  imposed.  In  some  cases,  a 
revision  may  .  me  from  a  revision  that  predates 
tne  immediate  predecessor  in  the  same  revision 
e.'t  n:  f r on  some  other  source  entirely.  Most 
operations  sum  as  opening,  reading,  writing, 
arid  Jeieting,  apply  to  individual  revisions  of  a 
revision  set.  sharing,  however  can  only  be 
*:runpl  Isneii  for  the  revision  set  as  a  whole. 
It  tne  last  revision  of  a  set  is  deleted,  the 
nu.t.er  is  r>ct  reused  when  the  next  revision  is 
c rested. 

To  provide  absolute  identification,  in-place 
editing  r.t  revisions  is  restricted.  Only  tne 
latest  memoer  jf  a  revision  set  may  be  modified 
in-place,  and  then  only  udder  certain  conditions. 
The  most  recent  revision  supersedes  all  previous 
revisions.  The  latest  revision  can  also  be 
t'xplii.itly  freren,  after  which  it  may  not  be 
muditied.  A  revision  can  become  unmooi f raoie 
tut  three  reasons: 

•  it  was  explicitly  frozen  ty  the  user  or 
a  program, 

•  it  is  not,  the  latest  revision,  or 

•  it  has  been  used  to  generate  another 
object  which  is  unuer  configuration 
control. 

only  in  the  last  case,  when  the  derived  object 
is  removed  from  the  database,  can  an  unmooi- 
fiaole  revision  again  become  modifiable.  In  the 
other  cases,  tne  action  of  freezing  is  irrevo¬ 
cable.  In  the  first  two  cases,  the  revision  is 
said  to  rie  frozen,  unmodifiabiiity  applies  only 
to  the  text  of  a  revision;  it  does  not  limn 
changes  tc  attributes  or  associatic  .  Each  re¬ 
vision  possesses  a  distinct  set  of  attributes 
and  associations.  Revisions  from  which  files 
jnder  configuration  management  have  been  derived 
nay  riot  be  removed  from  the  database  until  the 
derived  file  has  been  removed. 

A  by  revision  ran  be  named  by  attaching  a 
parenthesized  revision  number  subscript  to  the 
pathname  of  the  file.  If  no  subscript  is  given, 
toe  latest  revision  is  assumed.  it  the  sub¬ 


script  "+"  is  specified,  the  latest  frozen 
revision  is  referenced.  T  tie  latest  frozen 
revision  is  either  the  last  revision  or  the 
next-to-last  revision.  The  use  of  subscript 
notation  promotes  the  view  that  the  revision  set 
is  an  array  possessing  elements  that  are  the 
individual  revisions.  Figure  A  shows  the 
pathnames  of  three  different  revisions. 


3.4  Unique  Identifiers 

The  ALS  automatically  assigns  each  node  an 
identifier  which  is  temporally  and  spatially 
unique.  In  other  words,  once  assigned,  no  other 
node  in  any  ether  ALS  database  will  ever  have 
the  same  identifier,  unless  it  is  a  copy  of  the 
original.  Moreover,  once  assigned,  the  identi¬ 
fier  cannot  be  changed.  these  identifiers  are 
called  unique  identifiers  or  UIDs.  UIDs  have 
three  fields: 

•  object  serial  number  (10  bytes), 

•  ALS  database  identifier  (7  bytes),  ana 

•  organization  identifier  (10  bytes), 

An  object  serial  number  is  assigned 

automatically  by  the  AlS  each  time  a  node  is 
created.  To  that  is  appended  the  database 
identifier  which  is  unique  for  each  database 
within  an  organization.  Finally,  the  organi¬ 
zation  identifier,  naming  the  organization 
owning  the  database,  is  appended.  Database 
identifiers  are  administratively  assigned  by  a 
specifically  appointee  person  within  each 
organization  to  which  the  ALS  has  been 
delivered.  Organization  identifiers  are 
assigned  by  the  government  agency  responsible 
tor  configuration  management  and  distribution  of 
the  AlS.  The  name  space  is  large  enough  to 
aiiOw  tne  i  reation  of  10,000  nodes  per  second 

for  tt>  next  2.b  million  years  in  each  of  8 
trillion  databases  in  each  of  1400  trillion 
organizations.  with  simple  compression 
techniques,  only  10  bytes  Out  of  the  full  27 
bytes  won.  i  ijve  t  j  t.e  stored  tor  each  node. 

The  als  supplies  tools  for  copyina  nodes 
from  one  AlS  database  to  any  other  AlS 

database.  when  files  are  copied  in  this  way, 
the  original  and  the  copy  are  automatically 
frozen.  In  the  receiving  database,  cepies  are 
created  with  tne  same  UIDs  as  the  original.  It 
is  therefore  possible  to  compare  baselines  on 
two  hosts  by  comparing  only  the  UIDs  of  the 
files  in  the  base '  i  ;s.  Because  both  the 

origina1  and  copy  are  frozen,  there  is  a 
reasonable  level  of  confidence  that  tne  files 

are  the  same.  Without  this  capability,  it  would 
be  necessary  to  transmit  the  entire  contents  of 
ail  the  files  in  the  baseline  to  one  of  the 
hosts  where  an  exhaustive  file  comparison  would 
have  to  be  run.  Recording  the  UIDs  of  files 
from  which  an  installed  system  is  built  provides 
a  similar  level  of  control  for  delivered 
software  which  may  not  reside  on  a  host. 
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3 . 3  Variation  Sets 

To  represent  families  of  programs,  the  ALS 
provides  a  construct  called  the  variation  set. 
Menders  of  variation  sets  are  functionally 
similar  software  components  tnat  differ  in  their 
implementation  Details.  Since  variation  set 
members  go  not  supersede  one  anotner,  tney  are 
named,  not  numoered.  Nodes  called  variation  set 
headers  are  used  to  represent  variations  sets  in 
the  ALS  aatadase.  A  variation  set  header  can 
occur  anywhere  a  directory  noae  can  occur  except 
ai  the  root  of  the  database.  The  members  of  a 
variation  set  appear  as  offspring  of  the 
variation  set  header  node.  The  members  can  be 
revision  sets,  other  variations  sets,  ordinary 
subtrees  (i.e.,  directories),  or  any  combination 
or  these.  A  default  variation  can  be  designated. 

figure  B  shows  an  example  of  the  use  of 
variation  sets.  Variation  set  headers  appear  as 
hexagons.  In  this  example,  the  source  for 
matn_pac  exists  in  two  variations,  one  for  inte¬ 
ger  hardware  and  another  for  computers  with 
floating  point  hardware.  The  floating  point 
variation  is  further  divided  into  variations  for 
long  worus  and  short  woros.  Variation  set 
headers  are  similar  to  directories  except  that 


in  pathnames,  reference;  to  their  u,fsprinu 
appear  in  parentheses  rather  than  being  sepa¬ 
rated  uy  dots  from  the  nreceiiind  path  element . 
In  this  respect,  the  members  t  a  varisticr  vet 
are  viewed  as  array  elements,  where  the  element- 
are  named  rather  tnan  numbered.  F  inure  h  sn" w 
how  pathnames  with  variation  references  ir,: 
nested  variation  references  are  formed.  If 
empty  parentheses  are  specified  ana  a  default 
variation  nas  been  oesianated,  the  default 
variation  will  be  selected. 


3.6  Node  Sharing 

To  ensure  that  the  AlS  car  ieacilv  support 
many  scenarios  for  programmer  coordination, 
tnere  is  a  sharing  mechanism  in  addition  to  trie 
usual  copying  capability.  Any  node  may  be  shared 
provided  the  sharing  does  not  introduce  a  cycle 
into  the  database  structure.  In  essence, 
sharing  a  node  creates  an  alias  for  that  none. 
A  noae  may  have  two  Kinds  of  parents,  true 
parents  and  foster  parents.  A  true  parent  is 
the  directory  (or  variation  header)  j-->  which  the 
node  was  originally  created.  Every  node  nas 
exactly  one  true  parent.  A  foster  parent  is  a 
directory  (  or  variation  header)  that  subse- 


figure  B.  Variation  Sets 
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Ill  l>t 


Figure  C.  Node  Sharing 


quentiy  snares  an  existing  node.  A  node  may 
have  an  arbitrary  runoer  of  foster  parents. 
Figure  i_  snows  a  node  sharing  situation.  in 
this  rase,  ttit-  shurt  word  length  variation  of 
math  bat  snares  the  n" ,  "cos",  and  "series" 

files  witn  the  lung  word  length  variation. 
Notice  tnat  the  tayior  series  procedure  lias  two 

names,  " ,math_pac. source! f It pt ) ( long) .tayior" 

and  ”.ia tf ._pot. .  source  ( fi  t_pt ) ( short )  .series" . 
it  is  the  same  revision  set,  but  shared  with  a 
aif'reient  name  on  the;  link.  Individual  elements 
jt  revision  set  cannot  be  shared,  only  the 
wru.,-‘  set.  Directories  and  variation  headers 
may  also  be  shared. 

3 . 7  Attributes 

An  attribute  is  a  named  character  string 
.i'..r.'i:  l:.  describe  the  nude  which  possesses  the 
attribute,  a  none  may  have  an  arbitrary  number 
'  ulttUv.es.  Ibt.  ALS  uses  certain  attributes 
ti  •••  -nt rui  the  database  and  restricts  the  use  of 
"it"--  ittribulea.  F'rograms  can  create,  delete, 
sn ii :  ■■;,<. ar,»  ether  attributes,  subject  to  the 
■  -tt.ii  ic.es ,  controls.  There  is  no  global  list 
...if  ittritiutes  or  registration  procedure  for 
attributes.  Jtrier  than  the  attributes  useu  fur 
la*,  abase  control,  there  are  nu  att~  ibutes  that 
.■vi  v  "  iae  possess.  The  values  of  attri- 

bates  are  strings  which,  can  be  14,  to  64K  char- 
a'  ters  Lung. 

Attributes  can  be  used  to  select  varia- 
t  i.ibs.  Thic  is  accomplished  by  giving  a  se¬ 
quence  at  iname=>value)  pairs  in  place  of  the 
v.rrafiui'  name.  ft*-  pairs  are  separated  by 


commas.  Figure  D  shew  an  alternate  organization 
for  the  example  of  Figure  6.  In  this  case, 
instead  of  nesting  variations,  there  is  only  one 
variation  header  with  variations  named  "va", 
"vb",  anc  "vc".  Variation  "va"  of  "source"  has 
an  attribute  named  "mode”  with  a  value  "integer". 
Variation  "vb"  has  an  attribute  named  "mode" 
with  value  "flt_pt"  ana  another  attribute  named 
"size"  with  value  "long".  Finally,  variation  "vc" 
has  an  attribute  named  "mode"  with  value  ”flt_pt" 
ana  an  attribute  named  "size"  with  value  "short". 
Figure  D  shows  two  examples  of  variation  selec¬ 
tion  with  attribute  values.  Additional  varia¬ 
tions  and  selection  attributes  can  be  added 
dynamically  as  the  software  configuration 
evolves.  If  attribute  selection  is  used,  the 
specification  must  select  a  single  variation 
unambiguously . 


3.8  Access  Control 

AlS  access  controls  are  based  upon  a 
conventional  lock  and  key  mechanism.  Users  and 
programs  have  keys  ana  database  objects  have 
locks.  The  user  and  program  keys  must  match  the 
appropriate  lock  in  order  to  obtain  access. 
Attributes  are  used  to  store  the  locks  and  keys. 

tach  user  has  two  keys:  a  user  name  anci  a 
team  name.  The  user  name  is  determined  when  the 
user  enters  toe  Al.S  from  the  host  operating 
system.  The  team  name  may  be  chosen  by  the  user 
from  a  roster  of  team  names  an n  team  members 
controlled  administratively.  The  key  of  an 
executing  program  is  obtained  from  an  attribute 
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documental  ion 


sour t  tests 


.math  pac .  source(mode-  ‘integer ) .  taylor  math  jaac .  source  ( mode  Sflt_pt.size  -short ).  tay  lor 

Figure  0.  Attribute  variation  Selection 


named  "access_name"  attached  to  the  Ai.S  tile 
wne re  the  executable  inage  of  the  program 

T0  b  i  Jt-3  * 

LuLKi  die  attached  to  each  database  object 
with  attributes  named  read.  append,  write, 

attrj_+ianye,  execute,  and  via.  The  values  of 
tne st:  attributes  are  lists  of  the  keys  which 
will  .>atiafy  the  Iock.  The  lock  can  be  satisfied 
y  either  toe  tear,  name  or  the  user  name.  An 

iSteri-S-:  can  be  used  to  match  a  substring  of  all 
-e,s.  T  or  example,  the  roc*  "'Smith"  will  match 
all  J:,ers  with  a  Key  ending  in  "Smith".  The  key 
ni, itches  ail  Keys.  If  the  reaa  lock  is 

satisfied,  then  tne  user  may  examine  the  file  or 
may  learn  the  offspring  of  a  directory  or 
variation  heaaei .  If  the  append  lock  is 

satisfied,  tnen  tne  user  may  aoo  to  the  ena  of  a 
ti.u,  or  add  entries  to  a  directory  or  variation 
header.  If  the  write  lock  is  satisfied,  then 
the  user  may  change  a  file  or  add  and  delete 
entries  of  a  directory  or  variation  heaoei  .  If 
tne  attr_change  Iock  is  satisfied,  then  the  user 
nay  artel  tne  values  of  attiiDutes  anu  associa¬ 
tions  ano  add  and  delete  attributes  and  asso¬ 
ciations.  If  the  execute  loci-  is  satisfied,  the 
user  may  place  the  executable  image  or  command 
script  into  execution. 


The  via  lock  allows  the  creation  of  database 
objects  that  can  oe  accessed  only  by  programs 

intended  for  that  purpose.  It  tie  via  loo  Is 

not  empty,  then  the  key  of  the  program  used  tn 
access  the  object  must  satisfy  the  via  Iock. 
Even  if  the  via  Iock  is  satisfied,  “ito-r  the 
user  name  or  the  team  name  must  still  satisfy 
the  lock  appropriate  to  the  type  of  access 
desired.  If  t tie  via  lock  is  null,  any  urogram 

may  De  used,  provided  access  is  otherwise 
uranted.  This  feature  is  utilized,  for  example, 
to  prevent  the  user  from  altering  object  oaor 

produced  by  the  Ada  compiler. 


3.9  Associations 

Associations  are  similar  to  attributes,  ">.* 
used  to  document  the  relationships  between 
nodes.  The  value  of  an  association  is  a  list  o' 
pathnames.  The  ALS  ensures  that  the  elements  of 
the  list  are  syntactically  valid  pathnames,  hot 
otherwise  performs  no  validation  or  maintenance 
on  tne  list.  An  example  of  the  use  of  associa¬ 
tions  is  the  Ada  compiler  which  records  The 
names  of  previously  compiled  modules  r->fere<n  ed 
during  a  compilation  in  an  association  named 
"depends  on".  This  association  is  suhseguentlv 
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useu  by  tne  linker  to  enforce  tne  Ada  compila¬ 
tion  ordering  rules  by  checking  that  no  mouule 
named  in  a  "depends_on“  association  has  been 
compiled  later  than  the  module  which  possesses 

the  association. 


3.10  Derivations 

The  Stoneman  calls  for  the  generation  of 
detailed  histories  of  objects  unaer  configura¬ 
tion  management.  The  AL$  does  this  by  means  of 
derivations.  Any  ALS  file  can,  potentially, 
possess  =  derivation.  A  derivation  is  a  com¬ 
bination  of  attributes  and  associations  that 
document  tne  circumstances  under  which  a  file 
was  created  or  modified.  Comparison  of  deriva¬ 
tions  snows  wny  files  differ  rather  than  the 
exact  text  of  the  differences.  Although 
derivations  are  not  intended  or  used  for 
database  backup,  they  contain  enough  information 
so  tnot  tne  contents  o'  a  file  can  be  exactly 
recreated  from  tne  derivation  if  the  files  nameo 
in  the  derivation  exist. 

Files  in  tne  ALS  database  cart  only  be  created 
or  modified  during  tne  execution  of  some  program 
called  tne  creating  tool.  The  derivation  is  an 
accounting  of  tne  conditions  under  which  the 
creating  tool  executed.  The  name  of  the  program, 
the  parameters  passed  to  the  program,  and  files 
opened  anu  read  by  the  program  are  automatically 
recorded  in  tne  cerivation.  The  creating  tool 
can  modify  the  derivation  based  on  specific 
knowledge  that  a  particular  input  is  insignifi¬ 
cant  ci  tnat  some  other  nnrecordeo  information 
is  significant.  The  ALS  interrial  iy  maintains 
tne  information  required  for  derivations.  When¬ 
ever  an  output  file  is  CiLsed,  the  information 
is  posted,  if  derivations  Tave  been  enabled  by 
tne  creating  tool. 

a  derivation  consist;  of  the  attributes 
■derivation  tewt  arid  tne  associations 
iOgqed_inuut c ,  derived  fron  ana  other_inputs. 
Tnese  attributes  ano  associations  collectively 
constitute  the  derivation.  Derivations  are 
curt  roiled  t'y  trie  KMHSE  and  cannot  be  modified 
vt-t  .leutibg  tool.  Tne  functions  of 

•.no  ieriv.it  u.n  ..  mpneents  are: 


’•is  attribute  (  unve/s  tne  name  of  the  tools 
Mial  leated  _r  modified  tne  file,  the  para- 
:>'•  r  passed  to  those  tools,  and  annota- 
Ci'./m  pi  ted  by  these  tools. 

P  its 

'hi  is  .uciation  lists  the  pathnames  of 
that  were  opened  anp  read  by  the 
iting  tooi .  References  in  this 
•  inui.  Lafiun  engender  the  incrementation  of 
the  derivation  count  of  the  named  file. 


derived_from 

This  is  a  special  association  that  contains, 
not  pathnames,  but  the  unique  identifiers  o' 
the  files  named  in  the  logged  inputs 
association.  By  using  derived_f run ,  the 
files  named  in  tne  derivation  can  be  found, 
even  if  they  have  teen  renamed.  This  is 
used  by  the  Ai_b  when  decrementing 
derivatiori_counts. 

other_inputs 

This  association  lists  the  pathnames  of 
files  that  were  open  am  read  by  the 
creating  tooi,  but  were  not  entered  in  the 
logged_inputs  association  because  the 
citation  was  explicitly  suppressed. 
References  in  other_inputs  do  not  engender 
incrementation  of  the  derivation_count  of 
the  named  file. 


Files  which  have  been  named  in  the 
logged_inputs  association  of  the  derivation  of 
one  or  more  other  files  possess  a  cited_D> 
association  and  a  derivation  count  attribute. 
Citedjoy  contains  the  UID's  o7  the  files  that 
name  this  file  in  their  derivations.  These  are 
the  back-links  of  the  derived_from 
associations.  In  other  words,  cited_by  refers 
to  those  files  that  have  been  created  from  the 
file  possessing  the  citea_by  association. 
Derivation_count  is,  simply,  the  number  of 
entries  in  the  cited_by  association.  Cited  by 
and  derivation_count  are  managed  automatically 
by  the  ALS  and  are  not  subject  to  cirect 
alterations  by  tools  or  users.  Entries  in 
cited_by  are  removeo  when  the  named  file  is 
deleted.  A  revision  cannot  be  deleted  if  it 
possesses  a  positive  aerivation_count .  Since 
this  makes  deletion  very  complicated,  the  use  of 
derivations  is  recommended  only  for  baseline 
objects  unoer  configuration  management. 


Section  4 

USE  OF  ALS  FEATURES 

This  section  describes  how  the  features  of 
the  ALS  can  tie  used  to  overcomp  some  of  the 
problems  faced  in  large-scale  software  efforts. 
For  discussion  purposes,  the  use  of  variations 
will  be  illustrated  in  trie  context  of  providing 
support  for  program  families;  the  use  of  revi¬ 
sions,  access  control,  and  derivations  will  be 
outlined  in  relation  to  CM;  and  the  use  f 
sharing  will  be  couched  in  the  discussion  of 
programmer  coordination.  However,  in  reality, 
the  partitioning  is  not  as  clear.  Variations  are 
also  necessary  for  CM;  access  control  is  neces¬ 
sary  for  programmer  coordination;  and  all  aspects 
of  CM  are  intimately  related  to  programmer  co¬ 
ordination. 
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4.1 


Program  "amilies 


411  changes  to  software  components  fall  into 

two  classes: 

•  changes  that  make  previous  versions  of 
tne  component  oDsolete,  and 

•  changes  that  do  not  cause  previous 
versions  to  become  oDsolete. 

The  first  class  of  change  is  called  revision; 
the  second  is  termed  variation. 

Examples  of  changes  of  the  first  class  are 
error  corrections.  Once  an  error  is  discovered 
and  corrected,  there  is  no  reason,  other  than 
historical  investigation  of  failures,  to  use 
old,  erroneous,  versions  of  a  component  in  any 
new  systems.  The  latest  version  supersedes  all 
older  versions.  Revision  sets  are  used  to  repre¬ 
sent  this  type  of  change  in  the  ALS  database. 
Revision  aoes  not  give  rise  to  families  of  pro¬ 
grams.  If  all  components  are  changed  by  super¬ 
seding  the  previous  revision,  then  at  any  given 
time,  there  is  only  one  current  copy  of  the  soft¬ 
ware  incorporating  all  of  the  latest  revisions 
of  ail  components. 

Examples  of  changes  of  the  second  class  are 
changes  in  the  function  or  implementation  of  a 
component.  One  common  source  of  variation  is 
testing.  A  program  may  have  some  components 
used  only  during  testing  ana  other,  similar  but 
not  identical,  components  used  in  production 
variations  of  the  system.  In  this  case,  the 
existence  of  a  test  variation  does  not  make  a 
production  variation  oosolete;  the  variations 
legitimately  exist  simultaneously.  An  error  in 
one  variation  may  or  may  not  appear  in  another 
variation.  Variations  may  also  exist  because  of 
differences  in  implementation  of  identical 
functions.  Uur  SINE  routine,  for  example,  might 
be  coded  in  any  number  of  languages  for  different 
computers.  There  may  be  a  separate  variation 
for  computers  tnat  lack  floating  point  hardware, 
or  a  separate  double  precision  variation,  etc. 
AlS  variation  sets  are  useu  to  represent  changes 
of  this  type.  It  is  variation  that  gives  rise  to 
families  of  programs  because  multiple  systems 
oar i  De  constructed  by  incorporating  the  latest 
revision  of  one  or  another  variation  of  a 
component  in  each  of  the  systems. 

Variation  set  headers  mark  the  places  in  the 
software  where  evolution  of  the  families  di¬ 
verges.  Components  above  variation  headers  are 
shared  by  all  members  of  the  family  of  programs, 
components  below  variation  set  headers  are 
spec  it'ic  to  some  subset  of  family  members.  In 
general,  it  is  best  to  have  the  variation  set 
headers  as  low  in  the  structure  as  possible  so 
that  shared  components  do  not  appear  below  vari¬ 
ation  headers.  In  this  sense,  the  example  in 
figure  t.  is  less  than  ideal. 

4  single  functional  variation  often  results 
;  i  many  changes  distributed  throughout  the 


structure  of  the  baseline.  It  a  single  varia¬ 
tion  header  were  used,  it  would  have  to  be 
placeu  so  high  in  the  structure  that  many  commor 
components  would  appear  in  the  Subtree  of  the 
variation  header.  In  such  cases,  it  is  better 
to  use  multiple  variation  headers  for  a  single 
functional  change.  However,  each  of  the  resuit¬ 
ing  variations  should  either  be  given  the  same 
name,  or  should  all  have  common  identifying 
attributes.  Fur  example,  if  a  variation  is 
introduced  in  a  system  to  support  double  preci¬ 
sion  arithmetic,  then  all  components  that  are 
specific  to  single  precision  shoulc  be  named 
"single"  ana  components  specific  to  double 
precision  should  be  named  "double."  Using  the 
variation  notation,  this  would  yield  names  like 
sinei single) ,  cosine( single) ,  etc.,  in  one  case, 
ana  sine(oouble) ,  cosine(douhle) ,  etc.,  in  the 
^ther  case.  Alternatively,  attribute  variation 
selection  could  be  used,  in  which  case  the 
corresponding  component  names  would  be  sine 
(precisions  single),  cosine(precision=>  single), 
sine(precision=>  double) ,  and  cosine  {precisions 
double),  respectively.  Several  attributes  can 
be  used  for  selecting  a  single  variation,  e.y., 
sine(precisiun=>  double,  targets  8086).  In  this 
way,  variations  with  different  names  can  be 
selected  with  a  common  set  of  attributes. 

The  ALS  supplies  these  capabilities  so  that 
tools  for  constructing  individual  members  of  a 
program  family  can  be  readily  developed.  Such 
tools  would  tie  given  the  attribute  values  or 
variation  names  to  use  in  selecting  components 
from  a  baseline  containing  many  variations.  Tne- 
tools  would  then  collect  the  necessary  compo¬ 
nents  ana  oind  them'  together  to  form  an  execut- 
aDle  program..  Comoinations  of  many  attributes 
ana  variation  names  could  be  used  to  generate  a 
very  large  number  of  family  members  closely 
matched  to  the  requirements  of  individual  appli¬ 
cations.  Such  a  "custom  tailoring"  approach  to 
software  is  often  avoided  simply  because  conven¬ 
tional  methods  for  dealing  with  program  families 
are  cumbersome  and  expensive. 

The  proper  use  of  variations  can  lead  tc  sub¬ 
stantial  cost  savings  during  maintenance.  Con¬ 
ventionally,  members  of  a  program  family  are 
maintained  in  entirely  separate  baselines,  often 
by  entirely  separate  staff.  This  tends  to  en¬ 
courage  the  continued  divergence  of  the  family 
members,  even  when  it  is  unnecessary.  By  using 
variations,  a  family  of  programs  can  be  stored 
in  a  single  baseline.  This  approach  keeps  the 
evolution  of  the  software  from  diverging  to  the 
point  where  a  separate  maintenance  staff  is  re¬ 
quired.  Since  all  variations  are  readily  visible, 
grouped  under  a  single  header,  it  is  much  easier 
to  assess  the  effect  of  a  software  change  on  all 
members  of  a  family.  It  is  also  much  easier  to 
prevent  unnecessary  divergence  ana  easier  to 
apply  error  corrections  to  all  approriate  varia¬ 
tions. 

It  is  true  that  the  notion  of  variations 
could  have  been  supported  by  using  directories. 
However,  it  is  the  author’s  view  that  the  concept 
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will  ijf; I y  w.jik  successfully  it  p nil ;r smote r s  are 
" 1  t  *-  i 1 1 ... 1 1 . \  . :  a  t'n  difterence  between 

rev  1  ■>  inns  .tec  vuri.it  intis.  Every  Lime  a  change 
it  i:  U'Cm.p,:,  pi ;  crumnier  must  decide  whether 
trie  c  iciije  it  i  revisi..i  '  r  variation  ana  must 
r.t  the  ■ipprupriute  -tru  lure  tit  apply  the  change 
to  the  baseline. 


u.Y  Configuration  Management 

A  design  goal  of  the  ALS  was  tc  provide  the 
under  lying  nat.it  wenanisms  to  per  torn  con¬ 
figuration  management.  It  was  recognized  that 
there  ore  many  differing  scenarios  for  CM  and 
many  tools  that  can  do  implemented  to  support 
tnese  scenarios,  ‘-other  than  impose  one  metnod, 
the  ALS  supplies  the  fundamental  capaoilities 
which  iPoKe  ail  CM  tools  easy  to  implement.  Rudi¬ 
mentary  CM  tools  can  oe  implemented  directly  in 
the  4i_S  Command  language  without  writing  a  com¬ 
puter  program  in  the  conventional  sense.  An 
inpwementor  of  CM  tools  is  likely  to  rely  upon 
tne  following  AlS  mechanisms: 

•  revisions, 

•  unique  identifiers, 

•  variations, 

•  attributes, 

•  derivations,  and 

■  access  control. 

Revisions  ana  unique  identifiers  give  the  ALS 
user  the  means  to  absolutely  identify  software 
components.  The  use  of  variations  has  been 
treated  in  the  previous  section.  Attributes 
supply  a  method  of  attaching  descriptive 
information  to  an  object.  Derivations  provide  a 
detailed  accounting  of  how  an  object  was  created 
ano  why  it  differs  from  a  similar  object, 
f-iii any,  the  MLb  access  control  services  give 
tne  CM  tools  flexibility  in  restricting  access 
tu  baselines. 

Revision  sets  and  UlDs  are  the  keys  to 
absolute  identification;  and  absolute 
identification  is  the  key  to  configuration 
management.  Changes  to  baselines  are  made  by 
appending  revisions  to  revision  sets  and  then 
freezing  the  latest  revision.  From  then  on,  the 
name  of  the  revision,  say  sine(6),  stands  for 
that  ooject  ana  that  object  only.  Any  change  to 
sine  would  result  in  a  new,  highly  visible, 
revision  named  sine(7),  which  has  a  new  UID. 

Revision  pets  facilitate  the  comparison  of 
baselines  with  other  baselines  and  installed 
systems,  two  fundamental  CM  operations.  Suppiose 
tti.it  there  exists  a  baseline  from  which  is 
generated  a  number  of  variants  of  a  system.  The 
systems  are  constructed  by  a  tool  such  as 
best  ripen  in  the  previous  section.  As  a  system 
is  constructed,  tne  tool  proouces  a  component 


list  ct  tne  revisions  incorporated.  For  earn 
sjnponent,  the  list  contains  the  full  file  name, 
including  the  revision  number  ana  any  variation 
name,  rnd  the  uIU.  Every  system  constructed  foi 
testing  ana  every  system  generated  for  revenue 
service  has  its  component  list  attached.  The 
elements  of  any  system  can  be  readily  identified 
py  examining  its  component  list.  If  a 
programmer  needs  to  examine  the  source  text  of 
tne  system,  he  merely  displays  the  contents  u f 
the  revisions  specified  in  the  component  iief. 
Since  the  revisions  citco  in  the  component  list 
am  frozen,  there  is  nc  question  that  the  source 
text  is  exactly  tnat  used  to  generate  the 
system.  Any  change  between  the  given  system  and 
the  current  baseline  can  be  rapidly  identified 
fiy  comparing  the  revision  numbers  ang  Ulus  in 
the  component  list  with  the  latest  revision 
numbers  ana  UIOs  ir.  the  baseline.  The  system 
can  be  exactly  recreated  by  extracting  from  the 
baseline  the  revision:,  cited  in  the  component 
list.  Finally,  the  correspondence  oetween  a 
test  system  and  a  pruducticn  system  can  be 
easily  verified  by  comparing  the  component  lists 
Of  tne  systems. 

In  a  tuition  tc  system  building  tools,  CM 
typically  entails  tne  creation  of  many  tools  for 
such  tasks  an  installation  ana  accounting  of 
baseline  changes,  tracking  of  error  reports, 
tracking  o'  project  status,  baseline  inventory 
and  audit,  error  diagnosis,  etc.  Tools  of  this 
nature  often  require  auxiliary  information  about 
the  objects  in  the  baseline,  e.g.  installation 
date,  author,  pending  changes,  systems  in  which 
tne  object  was  usee,  etc.  ALS  attributes  are 
used  to  conveniently  store  such  auxiliary  infor¬ 
mation. 

Attributes  are  a  method  of  attaching  de¬ 
scriptive  information  to  an  object  without 
modifying  the  contents  of  an  object.  without 
attributes,  there  are  three  choices:  modify  the 
object,  builo  auxiliary  files  to  contain  the  de¬ 
scriptive  information,  or  use  naming  conventions. 
Modification  of  the  object  is  very  inflexible 
since  it  affects  the  programs  that  manipulate 
the  object.  This  approach  leads  to  such  aber¬ 
rations  as  highly  coded  control  information  em¬ 
bedded  iri  comments  in  source  code.  Naming  con¬ 
ventions  are  inadequate  for  the  amount  of  infor¬ 
mation  necessary  for  configuration  management. 
It  auxiliary  files  are  used,  each  program  that 
uses  them  must  build  ana  maintain  the  data 
structure  of  the  auxiliary  file.  Rv  providing 
attributes,  much  of  the  data  manipulat ion  burden 
is  removed  frnm  the  configuration  management 
programs.  Attribute  values  can  be  quite  large, 
up  to  64 K  characters.  Attributes  are  used  where 
the  information  is  to  he  kept  with  tt  e  object 
being  described.  Auxiliary  files  will  till  be 
used  where  information  about  many  object,  is  to 
be  collected  in  one  place. 

Derivations  are  required  bv  the  '-tonem, an. 
In  essence,  they  are  a  semi-automatic  method  fur 
incremental  iy  trace  inn  the  hlstorv  nf  software 
components.  In  fact,  the  Stoneman  uses  tt*  term 
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"history  att:  ibute. "  I  tic  AlL  implement«tior  ut 
derivations  is  similar  to  the  implementation 
proposed  ii'  the  Ada  Support  System  Study  '.vim- 
pie  tec  in  the  UK  iSTENj.  A  common  LM  operation 
is  toe  comparison  pf  components  to  identify  the 
differences  between  the  previous  software  that 
'uni.  tinned  correctly  arid  tne  current  software 
that  malfunctions.  Unfortunately,  direct  tex¬ 
tual  comparison  is  often  useless.  for  example, 
the  textual  comparison  of  object  modules  will 
usually  establish  that  a  difference  exists,  but 
rarely  yields  a  clue  auout  the  significance  of 
tne  difference.  Textual  comparison  of  source 
may  not  tie  much  more  enlightening  about  the 
relevance  of  any  differences  discovered.  How¬ 
ever,  comparison  of  the  derivations  of  two  com¬ 
ponents  can  reveal  that  different  revisions  or 
variations  of  source  were  used  to  obtain  object 
modules,  or  that  different  compiler  options, 
e.g.  optimization,  were  used  in  each  case,  etc. 
CM  tools  can  post  any  relevant  information  in 
the  Gerivat ion  text  attribute.  This  might  in¬ 
clude  a  component  list,  or  a  short  description 
of  a  change  entered  by  the  programmer  during  an 
edit  operation.  This  type  of  information  is 
significantly  more  useful  than  textual 
comparison  uy  itself. 

Access  to  baselines  must  be  controlled  to 
ensure  that  no  unaotnorizeu  changes  are  applied, 
fne  ALS  uses  a  relatively  conventional  paradigm 
for  access  control,  for  Cm,  the  via  lock  is 

especially  useful.  with  the  via  lock,  it  is 

possible  to  create  subtrees  in  the  ALS  database 
that  can  only  be  accessed  through  the  services 
of  a  tool  or  group  of  tools.  In  this  way, 
access  to  baselines  can  oe  controlled  by  CM 

tools  created  for  the  purpose.  Such  toois  are 
used  to  ensure  that  changes  are  applied  in  an 
orderly  fashion,  that  all  recording  of  changes 
is  duly  performed,  that  changes  have  been 
authurizeu,  and  so  forth.  This  feature  is  used, 
for  example,  by  tne  ALS  Ada  compilers  to  deny 

jsers  direct  access  to  program  libraries  where 
object  modules  are  stored.  In  this  way,  the 
user  is  prevented  from  circumventing  the 
recompilation  ordering  rules  of  the  Ada 
Lanyuage. 


A . 3  Coordination  of  Programmers 

This  discussion  will  be  limited  to  program¬ 
mer  coordination  during  the  manipulation  of 
source  and  object  code.  There  are  many  other 
aspects  of  programmer  coordination  not  t.eated 
her  ■  because  the  ALS  currently  provides  no 
specific  tools  for  interface  control,  design 
coordination,  requirements  analysis,  etc.  Some 
of  these  problems  are  addressed  by  the  Ada 
language;  others  will  be  addressed  by  tools 
written  for  the  ALS.  It  is  expected  that  the 
features  of  the  ALS  already  outlined  will 
simplify  the  implementation  of  such  coordination 
tjuis.  Many  of  these  tools  will  follow  the  CM 
paradigms  established  for  baseline  control. 


For  source  code,  most  coordination  will  ot 
done  by  the  use  of  baselines.  Source  used  by 
more  than  one  programmer  will  be  stored  in  a 
controlled  baseline.  Any  modifications  to  the 
source  will  he  accomplished  by  first  locking  the 
code  to  be  modified,  performing  the  modifica¬ 
tions  and  testing  them  in  a  private  area,  then 
installing  the  modifications  in  the  baseline, 
after  suitable  notice  has  been  given  to  all 
interested  parties.  Locking  prevents  more  than 
one  person  from  modifying  a  component  simulta¬ 
neously.  It  also  serves  to  alert  other  users 
that  a  modification  my  soon  be  applied. 

The  baseline  can  ue  used  in  three  ways: 

•  source  tiles  can  :;e  copied  from  the 
baseline, 

•  any  subtree  can  he  shared,  or 

■  the  baseline  can  simply  be  referenced. 

If  source  is  copied,  then  the  programmer  is 
insulated  from  any  changes  that  occur.  He  is 
also  cut  off  from  any  error  corrections  or 
improvements.  If  the  source  is  shared,  new 
revisions  of  the  source  files  will  automatically 
appear  in  the  sharer's  area,  potentially  witnuut 
notice.  If  the  source  is  referenced,  then  there 
are  a  number  of  choices,  references  to  explicit 
revisions  ana  variations,  references  tc  the 
latest  revision  or  latest  frozen  revision,  and/ 
or  references  to  tne  default  variation.  Ex¬ 
plicit  references  provide  isolation,  general 
references  do  not. 

Sharing  prevents  unnecessary  divergence  of 
software.  In  more  conventional  systems,  sharing 
is  accomplished  by  copying.  But  once  copied, 
the  evolution  of  software  components  is  likely 
to  diverge  because  the  copy  will  be  overlooked 
during  maintenance,  with  sharing,  there  is  only 
one  copy  to  maintain.  If  changes  for  one  sharer 
are  inappropriate  for  all,  then  a  variation 
should  ue  introduced  to  document  the  divergence. 
Keeping  all  the  source  logically  in  the  baseline 
anu  only  referencing  it  during  compilation  is  a 
good  compromise.  Isolation  can  be  achieved  by 
using  explicit  revisions  and  variations,  but  the 
divergence  of  evolution  is  less  likely.  However, 
with  referencing,  deletion  of  old  revisions  must 
be  controlled  to  avoid  deletion  of  source  text 
that  is  still  in  use.  In  some  sense,  this  is  an 
abrogation  of  the  obsolescence  property  of  re¬ 
visions,  and  therefore  should  not  be  usee  in 
place  of  variations.  In  other  words,  explicit 
revision  references  should  only  appear  when 
there  is  an  intent  to  track  the  evolution  of  the 
source  component;  otherwise,  a  variation  should 
be  created. 

The  ALS  supplies  much  stronqer  support  for 
programmer  coordination  at  the  object  code  level. 
All  Ada  object  code  must  be  placed  in  a  structure 
called  a  Program  Library.  In  general,  there  is 
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oiil-  Program  Library  (PL)  for  each  variation  of 
an  executaole  program.  A  PL  is  a  collection  of 
directories  anti  revisions  in  one  subtree.  Via 
locks  are  usea  to  restrict  access  to  PLs.  Pro- 
granmers  are  encouraged  to  think  of  PLs  as 
buckets  into  which  they  place  components  of  a 
system,  wrier,  all  components  are  in  the  PL,  they 
can  be  linked  together  to  form  an  executable 
program.  Revisions  are  used  inside  PLs  so  that 
one  PL  can  be  repeatealy  used  for  recompilation 
ana  relinking  during  the  system  development.  Ada 
recompilation  ordering  rules  are  enforced  by  all 
tools  that  operate  on  PLs. 

Components  can  be  placed  into  a  PL  by  com¬ 
pilation  or  by  acquisition  from  another  PL. 
Suppose,  for  example,  that  an  Ada  package  exists 
for  trigonometry.  The  package  can  be  initially 
compileu  into  a  puolicly  available  PL.  Program¬ 
mers  who  use  the  package  can  then  acquire  the 
object  code  directly  without  recompilation. 
Tnis  is  done  by  using  a  tool  named  LIB,  short 
for  library.  Acquisition  is  accomplished  by 
reference,  so  that  duplicate  storage  of  the 
object  code  is  avoided  while  maintaining  isola¬ 
tion  of  PLs.  Changes  in  the  acquired-f rom  PL  do 
not  automatically  appear  in  the  acquired-to  PL. 
The  addition  of  a  subscription  capability  is 
anticipated.  With  this  mechanism,  the  owner  of 
an  acquired-to  PL  would  be  notified  if  any 
changes  were  made  in  the  aqcuired-from  PL.  He 
could  then  reacquire  at  his  option.  PLs  provide 
the  isolation  of  copying  without  the  duplication 
of  storage.  Acquisition  can  oe  done  from  a  base¬ 
line  to  a  private  PL  to  establish  a  private  work, 
area.  The  acquisition  mechanism  provides  a 
method  for  easily  sharing  wnile  still  preserving 
some  isolation.  The  guiding  philosophy  behind 
PLS  is  that  neither  a  baseline  nor  a  private  PL 
can  oe  altered  without  explicit  action  by  the 
owner. 


Section  5 


•  explicit  named  variations, 

•  freezing  uf  revisions,  and 

•  derivations. 

The  notion  that  there  is  a  qualitative  difference 
between  revision  and  variation  has  been  inde¬ 
pendently  proposed  by  two  other  investigators, 
Cargil  and  Tichy.  The  ALS  will  test  the  value 
of  this  model  by  exposing  the  idea  to  a  large 
number  of  software  engineers  in  production 
situations.  In  the  author's  opinion,  the  dis¬ 
tinction  between  revision  and  variation  will 
prove  to  De  a  fundamental  notion. 
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LEARNING  THE  ADA  INTEGRATED  ENVIRONMENT 


George  Snyder 


Intermetrics,  Inc. 
Cambridge,  Massachusetts 


The  Ada  Integrated  Environment  (A IE)  is 
designed  to  be  easy  to  learn  and  easy  to 
use.  It  will  be  powerful,  efficient,  and 
friendly.  This  paper  describes  how  these 
goals  are  addressed  in  the  design  of  the 
Ada  compiler,  the  MAPSE  Command  Language, 
and  the  Program  Integration  Facility. 
Plans  for  future  tools  are  also 
described. 


The  Ada*  Integrated  Environment  (AIE) 
provides  support  for  the  development  of 
Ada  programs.  A  good  environment  should 
provide  the  power  and  flexibility  to  make 
program  development  as  easy  as  possible. 
It  should  also  be  friendly  and  easy  to 
use. 

An  environment  must  meet  all  these  cri¬ 
teria  if  it  is  to  be  easy  to  learn.  Pro¬ 
gram  development  tools  which  are  slow  or 
produce  poor  output  discourage  the  user 
from  learning  by  experimentation.  Lack 
of  flexibility  in  tools  frustrates  a 
novice  user,  and  often  force  experienced 
users  into  arcane  methods  which  are 
unreliable  and  difficult  to  maintain. 
Friendliness  and  ease  of  use  help  users 
get  started  in  the  environment.  However, 
a  user  advancing  into  unfamiliar  areas 
should  not  be  hampered  by  unneeded 

This  paper  describes  the  major  user 
interfaces  currently  being  developed  for 
the  Ada  Integrated  Environment:  the  Ada 
compiler,  the  MAPSE  Command  Language 
(MCL) ,  and  the  Program  Integration  Facil¬ 
ity  (PIF).  The  MCL  is  part  of  the  Minimal 
Ada  Programming  Support  Environment 
(MAPSE) 


The  MAPSE  Command  Language  (MCL) 
[Shenker]  is  the  primary  interface 
between  a  user  and  the  AIE.  The  funda¬ 
mental  role  of  the  MAPSE  Command  Proces¬ 
sor  is  to  invoke  programs,  in  response  to 
a  user's  MCL  commands.  The  overall  philo¬ 
sophy  of  the  MCL  is  similar  to  that  of 
UNIX  (R)  [Bourne] ,  a  widely  used  and  fam¬ 
iliar  system.  Because  MCL  syntax  is 
based  on  Ada  end  UNIX,  users  will  find  it 
easy  to  learn. 

The  MCP  uses  a  "toolkit"  approach, 
whereby  a  number  of  generalized  tools  can 
be  easily  interconnected  for  a  particular 
purpose.  All  tools  are  available  at  the 
command  level,  or  in  scripts  containing 
MCL  commands.  Because  tools  are  pro¬ 
grams,  rather  than  being  embedded  in  the 
command  processor  or  operating  system, 
the  tool  set  can  be  expanded  or  modified. 
Following  this  philosophy,  the  MCP  itself 
is  a  tool. 

Like  Ada,  MCL  may  be  typed  in  free  for¬ 
mat.  Because  MCL  is  primarily  an 
interactive  language,  Ada  syntax  rules 
have  been  relaxed  to  reduce  the  typing  of 
punctuation  such  as  parentheses,  commas, 
and  semicolons. 


A  program  is  invoked  by  typing  its  name. 
Suppose  there  is  an  Ada  procedure: 


procedure  Compile  (  Source:  string; 

Library:  string) ; 


This  program  could  be  invoked  with  a  com¬ 
mand  like  the  following.  Any  combination 
of  positional  and  named  parameters  may  be 
used: 


*  Ada  is  a  registered  trademark  of  the 
U.S.  Department  of  Defense  (AJPO) . 


compile  Mysource  Library  =>  Mylib 
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2.2 


Pipes 

The  Ada  predefined  text  input/output 
files  STANDARD  INPUT  and  STANDARD_OUTPU  T 
can  be  redirected  either  to  disk  files  or 
to  other  programs  via  "pipes."  Programs 
connected  by  pipes  execute  concurrently. 
In  the  following  example.  Sort  reads  its 
input  from  File]  and  passes  its  output  to 
Unique,  which  reads  the  result  as  its 
input  and  places  its  output  in  File2: 


Sort  -<  Filel  -|  Unique  ->  File2 


2 . 3  Language  Elements 

MCL  provides  a  number  of  Ada-like  con¬ 
structs,  as  well  as  all  Ada  operators. 
Literals  and  implicitly  declared  vari¬ 
ables  may  be  of  type  integer,  float, 
boolean,  or  string.  Quotations  around 
string  literals  are  optional.  A  variable 
may  also  be  given  an  aggregate  value;  its 
components  may  then  be  specified  either 
by  number  (as  an  array)  or  by  name  (as  a 
record).  Certain  attributes  are  defined 
for  MCP  variables,  such  as  'TYPE  and 
'LENGTH.  The  following  examples  illus¬ 
trate  some  of  these  features: 


%varl  :=  4 

%var2  :=  (A  =>  9,  B  =>  "Series  9") 
%result  :  =  5.0  +  3  *  (4  /  %result) 
put  %var2 ' type 
put  %var2 .B' length 


2 .4  Control  Structures 

Control  constructs  include  if-then-el se , 
case,  loop,  and  begin-end.  These  con¬ 
structs  may  be  nested,  and  may  be  invoked 
either  from  the  keyboard  or  from  a 
script.  When  a  compound  command  is  being 
entered  from  the  keyboard,  MCP  prompts 
with  line  numbers  until  the  command  is 
completed.  A  compound  command's  output 
may  be  redirected.  The  following  example 
sorts  a  list  of  colors  and  places  the 
result  in  Sor ted_ Colors  (a  colon  is  the 
normal  MCP  prompt): 


:  for  %color  in 

2/  (green,  blue,  red,  yellow)  loop 
3/  put  %color 

4/  end  loop  -|  sort  ->  Sorted_Colors 


2 .5  Scripts 

A  frequently  used  sequence  of  MCL  com¬ 
mands  may  be  saved  as  a  script,  resulting 
in  a  new  tool.  A  script  may  specify 
parameters,  like  an  Ada  procedure  or 
function,  and  the  parameters  may  have 
default  values.  A  powerful  aspect  of  this 
approach  is  that  an  Ada  subprogram  and  an 
MCL  script  are  invoked  in  exactly  the 
same  way.  Thus  frequently  used  scripts 
can  be  converted  to  Ada  without  hcving  to 
change  scripts  which  use  them.  Here  is  a 
script  which  performs  a  bubble  sort: 


IData  :=  (  5,  2,  4,  0,  1,  3  ) 

put  "Unsorted  Data:  ",  %Data 

for  %i  in  reverse  1 ..( %Data ' length-1) 
loop 

for  % j  in  1 . .% i  loop 

if  %Data(%j)  >  %Data(%j+l)  then 
%Temp  :=  %Data(%j+l) 

%Data (% j+1)  :=  %Data(%j) 
%Data(%j)  :=  %Temp 
end  if 
end  loop 
end  loop 

put  "Sorted  Data:  ",  %Data 


2 .6  Help  Facility 

A  help  facility  is  provided,  which  allows 
the  user  to  get  information  about  any 
program  or  MCP  script.  Help  is  also 
available  for  a  program's  parameters, 
simply  by  typing  a  question  mark  where 
the  parameter  would  normally  be  speci¬ 
fied. 


2.7  Other  Commands 

Any  command  may  be  executed  in  the  back¬ 
ground  by  terminating  the  command  with 
The  user  will  be  informed  when  the 
background  command  completes.  The  WAIT 
command  causes  MCP  to  wait  until  a  speci¬ 
fied  background  command  completes.  A 
background  command  can  be  terminated  with 
the  ABORT  command. 


:  comp: 

2/  compile  Myfile  Library  =>  Mylib  -& 
COMP  EXECUTING 
:  abort  comp 

COMP  ABORTED 
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A  user  may  end  his  MCP  session  with 
either  LOGOUT  or  SUSPEND.  In  the  latter 
case,  the  session  may  be  later  resumed  at 
the  state  in  which  it  was  suspended. 


3.  E&QGBAfl-  -LMT  EG  RATION 

The  purpose  of  the  Program  Integration 
Facility  (PIF)  is  to  create  &  manage  pro¬ 
gram  libraries  with  minimal  direction 
from  users.  In  addition  to  the  usual 
library  support  functions,  PIF  provides 
configuration  management,  including  ver¬ 
sion  control  and  automatic  reconstruction 
of  library  objects. 


3.1  Library  Support 

Multiple  libraries  can  be  maintained  in 
the  AIE,  and  one  or  more  libraries  may  be 
available  to  each  user.  One  of  the 
parameters  to  the  Ada  compiler  is  the 
name  of  the  library  into  which  the  compi¬ 
lation  is  to  be  placed.  If  the  library 
does  not  exist,  it  is  automatically 
created.  Mere  than  one  user  can  access 
the  same  library,  so  that  members  of  a 
team  can  share  program  units. 

In  order  to  save  space,  a  set  of  related 
library  units  which  are  frequently  used 
can  be  stored  in  a  catalog.  In  order  to 
save  space,  catalogs  can  be  shared 
between  libraries  in  a  manner  analogous 
to  a  traditional  library  of  object 
modules.  The  interface  catalogs  (specs) 
are  maintained  separately  from  implemen¬ 
tation  catalogs  (bodies) ,  and  multiple 
implementations  of  an  interface  can  coex¬ 
ist.  Users  can  specify  which  interfaces 
and  implementations  are  to  be  used  for  a 
particular  library. 


3.2  Configuration  Management 

The  PIF  supports  numbered  revisions  and 
named  versions  of  catalogs.  Users  can 
check  catalogs  out  for  modification,  and 
check  them  back  in  afterwards.  Inter¬ 
dependencies  of  objects  in  a  library  are 
tracked,  and  objects  are  reconstructed  as 
needed  so  that  any  referenced  object  is 
up-to-date. 


3.2.1  Version  Control  Since  Ada  units 
are  heavily  interdependent,  maintaining 
revisions  on  a  unit  basis  is  impractical. 
A  change  in  one  unit's  source  may  cause  a 
change  in  the  DIANA  of  every  unit  that 
depends  on  it.  For  this  reason,  versions 


and  revisions  are  treated  on  a  catalog 
basis.  A  user  can  link  to  the  latest 
revision  of  a  catalog,  or  to  a  particular 
revision  number. 

A  version  of  an  object  involves  signifi¬ 
cant  changes,  usually  including  unit 
specifications.  A  new  version  of  a  cata¬ 
log  is  created  by  copying  it  to  a  new 
name,  and  changing  a  library's  links  to 
it.  A  revision  is  typically  a  change  in 
implementation.  A  user  creates  a  revi¬ 
sion  of  a  catalog  by  deriving  from  it  a 
catalog  with  same  name  but  a  new  revision 
number.  Such  catalogs  can  later  be  pro¬ 
moted  to  resource  catalogs,  and  thus  made 
visible  to  other  catalogs. 


3.3  Object  Reconstruction 

The  PIF  makes  sure  that  every  object  in  a 
catalog  is  up-to-date  when  it  is  refer¬ 
enced  either  directly  or  indirectly. 
This  applies  not  only  to  Ada  units,  but 
to  other  kinds  of  objects.  A  user  can 
change  the  rules  and  tools  by  which  an 
object  is  updated. 


3.3.1  Initial  Form  A  library  object  may 
be  present  in  more  than  one  processing 
stage,  or  form.  such  as  "source," 
"abstract  syntax  tree  (AST),"  "diana," 
"object  module,"  "executabl e, "  "documen¬ 
tation,"  etc.  Each  object  in  the  library 
has  an  initial  form,  which  is  not  derived 
from  other  objects  in  the  libraty.  The 
initial  form  of  an  Ada  compilation  unit 
might  be  Ada  source,  or  Abstract  Syntax 
Tree  (AST) ,  for  example,  depending  on  how 
it  was  initially  submitted  to  the 
1 ibrary . 

Every  other  object  in  the  library  is  a 
generated  form,  and  is  derived  from  one 
or  more  initial  forms.  A  generated  form 
becomes  out-of-date  when  one  or  more  of 
its  initial  forms  is  replaced.  An  advan¬ 
tage  of  this  scheme  is  that  intermediate 
forms  can  be  deleted  from  a  library  to 
conserve  space,  without  causing  generated 
forms  to  become  obsolete. 

3.3.2  Rules  Rules  are  used  to  describe 
how  to  generate  one  form  of  a  library 
object  from  another.  The  general  form  of 
a  rul e  is: 

precursor  ->  target:  operation 

Users  can  modify  or  add  rules  to  cover 
other  forms,  such  as  foreign  language 
conversions,  documentation,  and  problem 
reports. 
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3.3.3  Approved  Operations  Operations 
are  maintained  in  a  list,  which  identi¬ 
fies  for  each  operation  a  tool  name  and 
revision.  Thus  tools  can  be  updated  or 
replaced,  without  changing  the  list  of 
rules.  Because  a  target_form  implicitly 
depends  on  the  version  of  the  tool  that 
creates  it,  updating  a  tool  may  cause 
some  objects  to  become  out-of-date. 


4.  AQA^£QHE1ULB 

A  compiler  may  be  a  programmer's  most 
important  tool.  The  AIE  compiler  is 
designed  to  produce  high  quality  code  in 
a  friendly  and  efficient  manner.  A  number 
of  optimizations  are  used  to  make  the 
generated  code  efficient.  Friendliness 
is  achieved  primarily  through  informative 
error  messages  and  a  powerful  syntactic 
error  recovery  (parse  fixup)  scheme. 


4 . 1  Compiler  Optimizations 


Compared  to  other  languages,  Ada  presents 
four  major  areas  of  difficulty  in  produc¬ 
ing  optimized  code.  Constraint  checks, 
several  of  which  may  occur  in  one  state¬ 
ment,  may  create  significantly  more  code 
than  the  programmer  expected.  Inline 
subprograms  expanded  in  a  simple  way  may 
make  modularity  expensive,  thus  defeating 
one  of  Ada's  primary  purposes.  Tasking, 
if  naively  implemented,  may  be  too  inef¬ 
ficient  for  some  synchronization  needs. 
Expansion  of  generics  must  be  optimized 
to  avoid  time  wasted  in  recompiling  gen¬ 
eric  bodies  and  space  wasted  by  redundant 
code . 


4.1.1  Constraint  Check  Elimination:  The 
AIE  Ada  compiler  eliminates  many  con¬ 
straint  checks  at  compile  time,  by  keep¬ 
ing  track  of  information  known  about  each 
object.  For  example,  a  simple  assignment 
of  one  variable  to  another  of  the  same 
subtype  does  not  require  a  constraint 
check,  because  the  source  variable  must 
already  contain  a  valid  value.  A  use  of 
a  variable  which  was  declared  with  an 
initial  value  does  not  require  a  con¬ 
straint  check,  since  the  initial  value 
has  already  been  checked.  The  sum  of  two 
integers  of  discrete  range  need  not  be 
checked  for  integer  overflow,  unless  the 
discrete  ranges  are  large. 

Implicit  constraint  checks  which  cannot 
be  removed  are  flagged  at  compile  time. 


With  careful  design,  a  programmer  should 
be  able  to  remove  nearly  all  such  checks. 
In  fact,  an  implicit  constraint  check  may 
often  be  taken  as  an  indication  of  a  flaw 
in  coding. 


4.1.2  Inline  Subprograms:  The  AIE  com¬ 
piler  fully  supports  inline  subprograms, 
and  optimizations  are  applied  after  such 
subprograms  are  expanded.  Thus  optimiza¬ 
tions  span  the  subprogram  interface. 


4.1.3  Tasking  Optimizations:  The  AIE 

tasking  implementation  is  optimized  in 
several  ways.  Nearly  all  scheduling 
overhead  is  eliminated  for  the  second 
task  of  a  pair  entering  a  rendezvous, 
since  the  other  task  is  already  waiting 
and  one  of  the  two  must  be  the  highest 
priority  runnable  task.  The  rendezvous 
is  executed  on  the  caller's  runtime 
stack,  so  that  parameters  are  passed  with 
the  same  efficiency  as  a  procedure  call. 
The  static  link,  which  would  normally 
point  to  the  innermost  invocation  of  the 
enclosing  subprogram  in  the  caller’s 
stack  frame,  is  adjusted  to  point  to  the 
called  task's  stack,  so  that  up-level 
references  refer  properly  to  the  scope 
containing  the  accept  body. 

In  addition,  the  user  may  declare  a  task 
which  does  nothing  important  outside  of 
accept  bodies  to  be  a  "monitor"  task. 
For  such  tasks,  even  more  scheduling 
overhead  and  nearly  all  stack  space  is 
el iminated. 


4.1.4  Optimizing  Generics:  Generics  are 
stored  as  DIANA  (an  intermediate  tree 
representation) ,  and  are  therefore  not 
recompiled  for  each  instantiation.  Where 
possible,  code  is  shared  among  instantia¬ 
tions,  to  minimize  redundancy. 


4 .2  Error  Reporting 

Accurate  diagnosis  of  syntactic  errors  is 
doubly  important.  First,  the  location 
and  nature  of  the  error  must  be  reported 
accurately.  Second,  the  parser  must 
recover  from  the  error  in  such  a  way  that 
artificial  errors  are  not  introduced.  In 
addition,  reporting  a  good  parse  fixup  is 
often  more  helpful  to  a  programmer  than  a 
good  error  message.  The  AIE  compiler 
uses  the  syntactic  error  diagnosis  and 
recovery  method  described  by  Burke  and 
Fisher  [BF].  Used  in  the  NYU  Ada-Ed  com¬ 
piler,  this  method  has  correctly  diag¬ 
nosed  over  fifty  errors  in  an  Ada 
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compilation  of  111  lines.  Some  typical 
messages  are  shown  in  figure  1. 

Semantic  errors  from  the  AIE  compiler  are 
designed  to  be  as  helpful  as  possible. 
Each  such  message  will  highlight  the 
erroneous  portion  of  the  source  line, 
describe  the  nature  of  the  error,  and 
give  a  reference  to  the  relevant  section 
and  paragraph  of  the  Ada  Language  Refer¬ 
ence  Manual  [ LRM] . 

The  semantic  error  handling  mechanism  is 
modular  and  flexible.  The  compiler 
defines  semantic  errors  at  the  levels  of 
declarations,  statements,  and  expres¬ 
sions.  There  is  a  unique  exception  for 
each  semantic  error,  so  that  an  error  can 
be  handled  at  any  of  several  levels. 
Since  an  error  handler  can  reraise  the 
same  exception  or  raise  a  different 
exception,  there  may  be  responses  on  more 
than  one  level.  An  error  in  an  expres¬ 
sion,  for  instance,  might  cause  the 
statement  in  which  it  occurs  to  be 
skipped.  responses  to  an  error  can  be 
easily  changed.  For  example,  messages 
describing  possible  causes  of  a  semantic 
error  and  suggestions  for  fixes  might  be 
added. 


5.  SUMMARY 

The  AIE  is  a  powerful,  easy-to-use 
environment  for  the  development  of  Ada 
programs.  It  provides  a  powerful  command 
language  based  on  Ada  and  Unix.  Its  pro¬ 
gram  integration  facility  supports  shared 
code,  and  helps  to  automate  revision  con¬ 
trol  and  object  reconstruction.  The  AIE 
compiler  is  production-quality  too]  which 
produces  optimized  code  and  and  helpful 
diagnostics. 
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Figure  1.  Example  Syntax  Error  Messages 


25  subtype  c  is  range  1..30; 

***  Syntax  Error:  "TYPE"  expected  instead  of  "SUBTYPE" 


39  x  :  =  x  +  2; 

***  Syntax  Error:  ":="  expected  instead  of  ":"  "=" 


46  begin 

47  declare 

48  x:  integer; 

49  for  i  in  1  . .  2  loop 

***  Syntax  Error:  "BEGIN"  expected  before  this  token 

50  b(i)  :=  0.0; 

***  Syntax  Error:  "END  LOOP;"  inserted  to  match  "LOOP"  on  line  49  at  column  27 
***  Syntax  Error:  "END;"  inserted  to  match  "BEGIN"  on  line  48  at  column  21 

51  end; 

52 

53  function  DAYS_IN_MONTO (M:  MONTH  IS^LEAP:  BOOLEAN)  return  DAY  is 
***  Syntax  Error:  "j"  expected  after  this  token 


91  K:  SHORT_ INT  =  1; 

***  Syntax  Error:  ":="  expected  instead  of  "=" 


106  elseif  z  >  w  then 

***  Syntax  Error:  Reserved  word  "ELSIE"  misspelled 


TEACHING  Ada  AT  THE  US  MILITARY  ACADEMY 


Major  Kevin 
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ABSTRACT — 'a  five  year  history  of  teaching 
Ada*  with  the  NYU  Ada/Ed  translator  has 
evolved  into  an  effective  methodology  for 
teaching  top-down  engineering  design 
simultaneously  with  a  bottom-up 
presentation  of  the  Ada  grammar.  With 
emphasis  on  embedded  hardware  systems, 
students  are  confronted  with  successively 
more  difficult  design  problems  which  must 
be  written  and  executed  on  a  VAX-11/780. 
Exposed  to  the  Ada  features  of  packages, 
concurrency,  generics,  and  exception 
handling,  students  design,  write  and 
execute  an  extensive  term  project 
simulating  a  real-time  embedded  system 
using  Ada.  Projects  approach  the  1000 
lines  of  source  code  limitation  of  the 
translator.  Reusability  of  code  is 
stressed  by  importing  a  previous  year's 
package  when  feasible. 

*Ada  is  a  registered  trademark  of  the 
U.S.  government,  Ada  Joint  Program 
Of  f ice . 


The  United  States  Military  Academy 
is  located  fifty  miles  north  of  New  York 
City  on  the  Hudson  River  at  West 
Point.  Every  year  nearly  one  thousand 
young  men  and  women  receive  a  Bachelor  of 
Science  degree  and  are  commissioned 
second  lieutenants  in  the  Army.  Like 
many  other  educational  institutions 
throughout  the  country,  an  increasing 
number  of  West  Point  cadets  enroll  in  the 
academy's  rapidly  expanding  computer 
science  curriculum  each  year.  Over  the 
last  five  years  Ada  has  been  part  of  that 
curriculum.  The  Department  of  Defense 
chose  the  Ada  programming  language  as  its 
weapon  to  combat  the  software  crisis  for 
embedded  computer  systems  for  the  1980's 
and  beyond.  It  is  a  natural  result  that 
West  Point,  the  Army’s  "college,"  has 
added  Ada  to  its  arsenal  of  computer 
science  studies. 


J.  Cogan 

and  Computer  Science 

Academy 

NY  10996 


AN  APPROACH  TO  ADA 

Ada  education  at  West  Point  began  in 
the  summer  of  1979  when  the  academy  was 
selected  as  one  of  the  first  locations  to 
conduct  an  Ada  workshop.  Recognizing  the 
impact  that  Ada  programming  was  to  have 
on  the  software  industry  as  well  as  the 
direct  applicability  of  Ada  for  the 
Department  of  Defense,  a  course  in  Ada 
programming  was  offered  for  cadets  in 
August  1980.  As  many  readers  of  this 
article  are  aware,  any  syllabus  for  a 
course  in  Ada  has  been  largely 
experimental  to  date.  A  good  case  for  a 
bottom-up  approach  to  Ada  education  can 
be  made  by  those  who  profess  that  the 
language  is  large  and  complex  and  must  be 
digested  at  the  syntactical  level  before 
the  concepts  unique  to  Ada  can  be 
introduced.  Proponents  of  a  top-down 
Ada  course  argue  that  programming  in  Ada 
requires  the  student  to  be  reoriented  in 
order  to  grasp  the  fundamental  aspects  of 
data  abstraction  and  packaging  in  Ada 
first,  and  then  master  the  syntax  which 
should  be  a  simple  process.  The  correct 
approach  may  ultimately  be  decided  by  the 
textbook  most  widely  used.  In  the  last 
year  many  new  Ada  texts  have  been 
published  since  the  Ada  language 
definition  was  approved  as  an  ANSI 
standard  in  Februaury  1983. 

The  primary  objective  of  Ada  education  at 
West  Point  is  to  determine  the  framework 
for  Ada  as  an  undergraduate  elective 
course  concurrent  with  providing  a  rich 
and  rewarding  programming  language 
experience  for  cadets.  This  effort  has 
been  in  cooperation  with  the  US  Army's 
'.’enter  for  Tactical  Computer  Systems 
(CENTACS)  at  Fort  Monmouth,  New  Jersey. 
As  the  prime  contracting  agency  for  the 
Army’s  first  production  compiler,  CENTACS 
has  provided  West  Point  with  successive 
versions  of  Ada/ED,  an  Ada  translator 
which  can  be  implemented  on  a  VAX 
m in icomputer . 
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THF  ADA'F.D  TRANSLATOR 


Ada  HD  is  a  product.  of  Now  York 
;  r,  i  wr  .iity's  Courunt  Institute  of 
M  itneatat  irs  under  contract  for  the 
Army.  Wr  Ltten  in  SKTL  which  itself  was 
developed  at  NYU,  Ada  ED  serves  as  an 
interim  learning  environment  for  Ada  until 
a  vosrpil"!  is  completed  and  released.  To 
date,  CKNTACS  has  provided  the  US  Military 
Academy  with  five  versions  of 
Ada  ED  -  i:.4,  li.5,  16.3,  17.2  and  ANSI 
Ada  ED  1 . i .  A) l  versions  have  been 
implemented  on  the  Department  of  Geography 
and  c'omput-'r  Science's  research  computer, 
a  VAX-11'780  minicomputer.  Each 
successive  version  has  resulted  in  faster 
translation  and  richer  semantic  error 
detect  lor  messages.  Access  to  Ada/Ed  has 
put  an  important  and  exciting  tool  in  the 
hands  of  cadets.  ANSI  Ada/ED  1.1  was  the 
first  compiler  or  translator  to  receive  a 
validation  certificate  from  the  Ada  Joint 
Program  Office.  validation  certifies  that 
a  product  fully  complies  with  the  ANSI  Ada 
language  definition.  ANSI  Ada/ED  can 
translate  100  lines  of  Ada  source  code  in 
approximately  200  seconds,  complete  with 
syntax  error  highlighting  and  semantic 
error  messages,  when 

appropriate.  Although  a  production  Ada 
compiler  will  be  several  orders  of 
magnitude  faster  than  this,  ANSI  Ada/ED 
has  provided  the  necessary  feedback  for 
cadets  and  instructors  to  assess  the 
learning  skills  acquired  in  the  classroom. 
West  Point's  findings  pertaining  to 
undergraduate  Ada  education  have  teen 
valuable  to  CENTACS  and,  hopefully,  to  Ada 
education  in  general. 


COURSE  FRAMEWORK 

The  first  course  in  Ada  at  West  Point 
was  simply  titled  Ada  Programming.  An 
assessment  of  student  background  was  made 
before  deriving  the  first  syllabus  foe  a 
course  never  previously  taught.  Cadets 
choosing  Ada  Programming  as  an  elective 
had,  as  a  minimum,  a  course  in  FORTRAN 
programming  during  freshman  year  (required 
for  all  freshman  cadets  regardless  of 
their  academic  major)  and  Structured 
Programming  in  Pascal  during  sophomore 
year.  Accordingly,  cadets  were  well 

prepared  for  Ada  as  another  language.  But 
it  was  realized  also  that  Ada  is  more  than 
a s t  another  programming  language  and  not 
oust  an  extension  of  Pascal.  The  birtii  of 
Ada’s  generic,  package,  exception,  and 
tasking  constructs  requires  a  new 

n  lent  at  ion  to  programming  if  the  full 
power  of  Ada  is  going  to  be 
r  il  Beyond  syntax,  there  are  the 

v:  • :  r e  of  readability,  reliability, 
T  i  l  nr  i  m  it,  i  1  1 1  y  ,  and  pot  tabi  ’  ity  to  be 
it  These  concepts  were  the  genesis 

>1  n *  Defense  Department's  pursuit  of  a 
: Tan  i  ir  !  language  for  embedded  computer 


systems.  Therefore,  it  was  reasoned 
that  a  course  in  Ada  must  somehow  embody 
these  concepts  and  make  them  an  integral 
part  of  the  course  structure. 

In  January  1982  the  course  name 
changed  to  Ada  Concepts  and  Programming. 
This  placed  emphasis  on  the  fact  that 
Ada's  concepts  were  on  a  par  with 
programming  as  required  learning 
objectives.  Cadets  must  demonstrate  that 
they  understand  the  concepts  of  Ada  as  a 
key  to  solving  the  embedded  computer 
system  software  crisis.  They  must 
understand  that  the  projected  defense 
software  budget  of  $36  billion  for  1990 
can  be  significantly  reduced  by  fully 
utilizing  the  concepts  of  Ada. 

INTEGRATION  OF  CONCEPTS  WITH  PROGRAMMING 

Presently  the  course  strives  to 
integrate  the  key  concepts  of  Ada  with 
hands-on  programming.  It  neither  purports 
to  be  a  top-down  nor  a  bottom-up  approach 
to  Ada,  but  rather  a  weaving  of  these  two 
approaches  throughout  the  forty  lesson 
attendances.  To  accomplish  this,  syntax 
learning  objectives  are  coupled  with  wnat 
might  be  an  actual  embedded  computer 
system  application. 

For  instance,  during  an  hour  lesson 
devoted  to  arrays  and  the  block-if,  the 
well-known  problem  of  counting  change  is 
used.  The  basic  purposes  of  loops  and  if 
statements  are  already  known  by  cadets 
naving  had  FORTRAN  and  Pascal 
previously.  The  notion  of  strong  and 
enumerated  typing  in  Ada  is  encountered 
before  this  particular  lesson.  Therefore, 
to  count  change  in  Ada  (see  Figure  1.) 
requires  only  mastering  the  new 
syntax.  An  opportunity  exists  at  this 
point  to  expand  the  problem  for  any 
monetary  system  based  on  100  as  in  100 
cents/dollar  or  100  pfennigs/W.  German 
mark.  An  immediate  problem  is  the  fact 
that  not  all  countries  based  on  100  have 
six  distinct  coins.  Further  it  might  be 
desirable  for  the  coin  machine  to  prompt 
the  user  with  a  voice  synthesis  module  for 
the  specific  unit  of  currency.  At  this 
point  Figure  1  is  obsolete. 

Figure  2  leads  (almost)  to  a  generic 
solution,  although  the  students' 
acquaintance  with  Ada  generic  units  has 
not  yet  been  firmly  established.  Of 
particular  note  in  this  solution  is  the 
FOR  LOOP  in  the  procedure  body.  Type 
COINS  is  the  range  governing  the  number  of 
iterations  of  the  loop.  It  no  longer  is 
dependent  on  the  integer  range  1..6  given 
in  Figure  1,  but  only  on  the  number  of 
values  enumerated  for  type  COINS  according 
to  the  nations  monetary 
system.  Concurrently,  because  the  loop 
index  implicitly  takes  on  the  type  and 
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current  value  of  the  range,  execution  of 
the  statement  PUT(N)  outputs  the  current 
coin  denomination  desired  followed  by  a 
user  input  to  that  coin  prompt.  Thus  to 
convert  this  program  for  West  German  use, 
the  programmer  changes  only  three 
statements  in  the  procedure  specification 
making  substitutions  as  follow: 

type  COINS  is  ( ONE_PFENNI GS , TWO_PFENNI GS , 
FI VE_PFENNIGS , TEN_PFENNIGS , 
FIFTY_PFENNIGS,ONE_MARK, 
TWO_MARKS,  F I VE_MARKS) ; 
type  MONEY  is  ( MARKS , PFENNI GS) ; 

VALUE  :  constant  array (COINS)  of  INTEGER 
:  =  (ONE_PFENNIGS  =>  1,  TWO_PFENNIGS  =>  2, 
F I VE_PFENN I GS  =>  5,  TEN_PFENNIGS  =>  10, 
F I FTY_PFENN 1GS  =>  50,  ONE_MARK  =>  100, 
TWOMARKS  =>  200,  FI VE_MARKS  =>  500) ; 

This  time  there  are  eight  enumerated 
values  for  type  COINS  resulting  in  eight 
iterations  of  the  loop,  but  this  should  be 
abstract  in  the  mind  of  the 
programmer.  The  executable  part  of  the 
procedure  requires  no  modification.  Eight 
coin  prompts  will  be  in  German. 

The  pedagogical  advantages  of  this 
program  should  be  clear.  First  there  is 
the  benefit  of  the  problem  solution 
itself.  Secondly,  aside  from  the  issues 
of  reliability,  the  classroom  example 
embodies  the  conceptual  goals  of  Ada.  It 
is  readable  with  virtually  no 

documentation  by  the  novice  Ada  programmer 
by  selecting  meaningful  names  for  types 
and  objects.  It  is  maintainable  due  to 
the  mere  three  statements  that  need  to  be 
altered  for  a  different  country.  it  is 
transportable,  not  only  from  the  Ada 
language  standardization  point  of  view, 
but  also  physically  transportable  from  a 
geographical  and  linguistic  sense  with  a 
minimum  of  recoding.  During  a  recent 
visit  by  an  Australian  official,  the  three 
statements  mentioned  above  were  quickly 
altered  to  reflect  the  five  subunits  of 
the  Australian  dollar  (1,5,20,50,100)  and 
thus  a  little  bit  of  Ada  is  now  at  work 
"down  under".  A  basic  tenet  of  Ada  is 
that  there  should  tie  a  minimum  of  recoding 
effort  when  changes  are  required.  Readers 
lamil iar  with  Ada's  generic  construct  can 
note  how  this  same  example  problem  can  be 
modified  and  written  later  in  a  generic 
package . 

HAND5-ON_ TRA 1 N I NG 

Few  educators  in  computer  programming 
languages  could  refute  the  benefits  of 
actually  running  programs  in  the  language 
being  taught.  Teaching  Ada  should  not  be 
an  exception  to  this  philosophy. 
Accordingly  it  has  been  found  to  be 
extremely  advantageous  to  get  students 
utilizing  the  translator  as  quickly  as 
possible.  One  lessor,  in  the  syllabus  is 


devoted  exclusively  to  using  the  Ada  ED 
translator  on  the  VAX.  Of  necessity,  the 
treatment  of  input/output  in  Ada,  chiefly 
in  terms  of  package  TEXT_IO,  is  moved  to 
the  beginning  of  the  course  syllabus  at 
about  the  sixth  lesson  so  that  students 
may  interact  with  the  execution  of  their 
program.  There  is  a  twofold  advantage  in 
this  approach.  Not  only  does  this  allow 
students  to  run  programs  early  in  the 
course  requiring  syntact ica 1 1 y  pure 
solutions,  but  it  also  allows  for  the 
early  introduction  of  the  concept  of 
packages  in  Ada.  Package  TEXT_IO  in 
Chapter  14  of  the  language  reference 
manual  is  rich  in  Ada  style  and  diversity. 
By  requiring  its  use  early  in  the  course 
of  instruction,  users  get  a  rudimentary 
application  of  such  constructs  as  generic 
package  instantiation,  subprogram  default 
parameters  -  NEWLINE  vs.  NEWLINE ( 3 ) , 
overloading  procedure  and  function  names, 
and  implementation  defined  values  for 
example.  The  WITH  and  USE  statements  must 
be  introduced  as  well,  thus  providing  a 
natural  environment  for  the  utility  and 
application  of  the  Ada  package.  Here  is 
the  essence  of  weaving  the  top-down  and 
bottom-up  approach  to  learning  Ada.  More 
details  of  subprograms,  generics,  and 
packages  come  later  in  the  course,  but  by 
lesson  9,  having  learned  the  minimal  set 
of  control  structures  to  solve  any 
problem,  students  are  ready  for  their 
first  hands-on  application  of  Ada.  A 
representative  problem  statement  is  stated 
as  follows: 

A  computer  terminal  manufacturer 
recognizes  that  terminals  will  continue  to 
progress  from  computer  terminals  to 
communications  terminals.  Products  such 
as  direct  connect  modems  should  allow  the 
user  to  directly  dial  a  telephone  number 
from  the  keyboard.  A  telephone  handset 
would  be  connected  to  the  terminal  for 
voice  communications  when  desired.  A 
typical  complaint  from  users,  however,  is 
that  keyboards  are  not  labeled  with  the 
alphabetic  letters  also  found  on  the 
telephone  dial  or  touch-tone  pad.  If  a 
mnemonic  such  as  ARMY  is  dialed  from  the 
West  Point  prefix  938,  a  tape  recording 
for  Army  sports  is  connected.  The  user  is 
hard  pressed  to  remember  the  numbers 
associated  with  A,  R,  M,  and  Y  as  2,  7,  6, 
and  9  respectively.  Further,  terminals 
should  be  intelligent  enough  for  this  to 
be  transparont  to  t h e  user.  A  typical 
telephone  dial  or  pad  is  arrayed  as 
f ol lows : 


AbCi 

t)FF 

Gil  f 

1 

2 

i 

4 

MNO 

PRS 

TUV 

WXY 

6 

7 

8 

9 
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The  manufacturer  desires  to  market 
terminals  with  embedded  software  written 
in  Ada  which  allows  the  user  to  dial 
through  a  direct-coupled  modem  by  either 
numeric  or  alphabetic  values  as  found  on 
the  array  above.  Write  a  program  which 
has  two  separate  procedures  to  accomplish 
the  following  tasks:  (1)  Enter  a  four 
digit  number  from  the  terminal  and  output 
to  the  terminal  on  separate  lines  an  array 
of  dots  corresponding  to  the  number  of 
each  digit  dialed;  (2)  Enter  on  separate 
lines  four  alphabetic  characters  (Q  and  Z 
not  allowed)  from  the  terminal  and  output 
to  the  terminal  on  separate  lines  an  array 
of  dots  corresponding  to  the  number 
associated  with  that  letter. 

An  student's  solution  from  this 
year's  course  is  at  Figure  3.  It 
represents  what  can  be  accomplished  by  the 
tenth  hour  of  instruction  in  a  hands-on 
course  in  Ada.  Readers  apprehensive  about 
the  size  and  complexity  of  the  Ada 
language  may  take  some  relief  at  this 
point.  The  student  is  in  his  junior  year, 
with  prior  experience  in  FORTRAN  and 
Pascal.  By  lesson  20  subprograms, 
packages,  library  units,  separate 
compilation,  and  exception  handling  have 
been  described.  A  problem  statement  is 
formulated  by  the  instructor  which 
incorporates  and  necessitates  these 
constructs  in  the  problem 
solution.  Similarly,  after  Ada  tasks  and 
generics  are  taught,  another  hands-on 
exercise  is  required.  With  approximately 
10  hours  of  instruction  remaining  from  the 
40  hours  allocated,  students  formulate 
their  own  term  project  in  consultation 
with  their  instructor.  Term  projects  may 
produce  a  useful  package  such  as  for 
trigonometric  functions  which  may 
subsequently  be  used  by  future  student 
projects  (this  has  already  been  done). 
Term  projects  also  may  emulate  a  present 
or  future  embedded  computer  system  such  as 
an  auto-rotat ion  procedure  to  safely  land 
an  incapacitated  helicopter  or  a  drone 
recona  issance  aircraft's  sensor  systems. 
Both  of  these  projects  lend  themselves 
nicely  to  Ada's  task  mechanism  for 
concurrent  processes.  Term  projects  are 
not  technically  complete,  but  they  do 
emulate  such  systems  from  a  design 
viewpoint  and  typically  range  from  500  to 
800  lines  of  code  which  must  be  executed 
on  Ada/ED. 


systems  which  can  stress  the  advantages  of 
an  Ada  problem  solution.  The  luxury  of 
having  the  Ada/ED  translator  available  to 
fully  exploit  the  education  process  has 
been  an  invaluable  tool  for  instructors 
and  students  alike.  Programs  emulating  a 
robotics  application  for  optically 
recognizing  resistor  color  codes  and  a 
self-service  package  mailing  station  for 
the  post  office  have  been  written  and 
successfully  run  by  cadets.  Stimulating 
problems  such  as  these  spark  the 
imagination  and  reveal  the  power  of  Ada. 
Solving  the  software  crisis  of  tomorrow 
requires  sowing  the  seeds  of  Ada  education 
today . 


Major  Kevin  J.  Cogan,  Department  of 
Geography  and  Computer  Science,  US 
Military  Academy,  West  Point,  NY  10996. 
Major  Cogan  was  commissioned  in  the  US 
Army  Signal  Corps.  He  received  a  BS 
degree  in  1971  from  the  US  Military 
Academy  and  an  MS  degree  in  Electrical 
Engineering  in  1981  from  Columbia 
University.  He  has  served  in  various 
command  and  staff  positions  in  the  US  and 
in  Europe.  Presently  he  is  an  assistant 
professor  of  computer  science  and  the  Ada 
course  director  at  West  Point. 


CONt .'I UN 

West  Point  is  corun  *  *  ?  **«i  ;r.  1 f  c 

pursuit  to  offer  quality  Ada  ed  ,  at  ion. 
It  requires  striking  .j  ha  i  in  «.’«*  iTtwo-n 
student  capabilities  and  ih**  Mmely 
introduction  of  -onceprs  unique  *■•>  Ada.  A 
mix  of  the  top-down  and  bottom- up  approach 
to  learning  Ada  has  evolved  using  the 
mechanism  of  example  problems  for  embedded 
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ABSTRACT 

t  i  r  •  - 1  Ada  c.-urse  at  lersev  Citv  State  Col- 
1  r,-«  -A.;  -  •  .tee  ••af  :  ieo.  Since  that  time, 

*  .  .  •*.-  :  A.: a  .n  ear  .  im;  :s  has  expanded  consider - 

c  ..  We  ::er  a  varietv  ■!  Ada  courses  and 

v.di.ati  o  Ada  have  Seen  i  tu  .>rporat  ed  into 

•:  c the:  =  or.putfr  cei;r-es  such,  as  Sot  tware  V.ngi- 
and  Svstems  P  re  ,•  r  nm*r.  i  n  g .  Under  a  contract 

*  :  t.  h  F>rt  Motrnouth  we  (I)  have  es  t  ah  I  i  shed  an  Ada 
'.e.  hr.  1  ot>v  'enter,  ( .")  have  produced  two  training 

•  'nr -.is  jor  Arr.v  use,  (}>  are  currently  dove*  1  opine, 
i.e  -tudv  extensions  o;  these  ceur-.es  and  (4)  are 
ex;-'  r  i  ne  t  fit  feasibility  or'  using  CA 1  ‘or  train- 

W.-  :■  ivr  established  a  I  iTtvon  with,  local  indus- 
t  rv  t-  e’-:  '.  ore  mutually  hetietici.il  ventures  and  in 
the  near  future,  expect  to  offer  special  seminars 
:  u  man a cement ,  scientists,  engineeis  and  college 
:  ni.Jtv.  We  are  also  , ensidering  wav  we  can  use 
Ada  as  a  first  or  Second  course  in  the  curriculum 
Cone,  with  some  software  engineering  concepts.  Our 
.wil  is  to  put  students  in  touch  with  cutting  edge 
t  ei  him !  o«:v  and  realistic  problems  as  soon  as  pos¬ 
sible.  > 

INTRODUCTION 

Tin-  first  Ada  course  at  Jersey  City  State  Col¬ 
lege  was  ram-lit  three  venrs  ago  by  Dr.  Philip 
Cavor’v,  currently  Chairman  of  the  Computer  Science 
Department  and  Director  of  the  Ada  Technology  Cen¬ 
ter  at  the  college.  Since  that  time,  Ada  courses 
have  been  given  regularly  to  a  wide  variety  of  stu¬ 
dents  -  including  undergraduate,  graduate  and  vis¬ 
iting  faculty.  Ada  has  been  used  as  a  Program  De¬ 
sign  language  in  our  Software  Engineering  course 
and  as  a  Systems  Design  Language  in  our  Systems 
Programming  course.  In  this  paper,  we  review  our 
experiences  with  the  use  of  Ada  in  our  courses  and 
explore  future  directions. 

Ada  COURSES 

We  have  structured  all  of  our  programming 
courses  so  that  students  can  start  writing  complete 
programs  almost  immediate  1 v .  As  new  topics  are  in¬ 
troduced,  they  are  incorporated  into  programs.  The 
package  concept  is  introduced  at  the  beginning  ot 
the  programming  courses  and  used  as  the  unifying 
thread.  We  discuss  the  use  of  packages  as  tvpes  and 
as  abstract  objects  along  with  the  concept  of  in¬ 
formation  hiding.  We  have  endeavored  to  use  Ada  as 


Ada  and  not  just  another  language  like  FORTRAN  or 
Pascal  with  somewhat  Jittering  syntax. 

1 .  TRAINING  COURSES  FOR  FORT  MONMOUTH 

In  1982  we  obtained  a  contract  from  the  Soft¬ 
ware  Technology  Development  Division  o 1  CENT ACS  at 
Fort  Monmouth  to  develop  two  Ada  courses,  a  Pro¬ 
fessional  Level  course  and  a  Technical  Level 
course.  The  former  is  intended  for  engineers  and 
computer  scientists  in  Government  service,  while 
the  Technical  Level  course  is  for  application  pro¬ 
grammers.  Each  course  was  designed  to  take  eight 
weeks  for  a  class  meeting  twice  a  week  for  two 
hours  per  session. 

Professional  Course  Content:  The  course  is  divided 
TiiTo 'seven  modules:  (I)  Packages  and  Input/Output, 

V  I  1 )  Encapsulating  Data  Types  in  Packages,  (III) 
Encapsulating  Data  Objects  in  Packages,  (IV) 
Encapsulating  Finite  State  Machines  in  Pack-ices, 

(V)  Tasking,  (VI)  Blocks  and  Exceptions  and  (VI!) 
Generics.  Each  module  takes  about  one  week  to  com¬ 
plete,  One  week  during  midcourse  is  used  tor  a 
review,  summary  and  breather. 

Technical  Course  Content:  (I)  Introduction  to 
Input /Out put,  (II)  Introduction  to  Ada  Structures, 
(111)  Introduction  to  Packages,  (IV)  Elementary 
Data  Structures  and  (V)  Advanced  Data  Structures, 
Testing  of  Professional  Course:  During  the  tost 
and  evaluation  period  the  course  was  given  at  Fort 
Monmouth  to  about  twenty  five  Fort  Monmouth  employ¬ 
ees.  It  was  a  heterogeneous  group  of  students 
with  a  variety  of  computer  backgrounds.  The  course 
was  restricted  to  those  with  no  prior  knowledge  of 
Ada.  In  general,  the  course  was  received  favorably. 
The  main  problems  encountered  were:  (1)  inhomoge¬ 
neous  student  backgrounds,  (2)  students  missing 
lectures  due  to  job  related  travel,  (3)  insuffi¬ 
cient  computer  time. 

Testing  of  Technical  Course:  The  material  in  this 
course  has  been  tested  in  a  one  year  undergraduate 
Ada  programming  course  described  below. 

2.  ONE  YEAR  UNDERGRADUATE  Ada  LANGUAGE 
PROGRAMMING  COURSE 

Currently,  many  co  ,  r  science  majors  at 
Jersey  City  State  College  take  a  one  year  course 
in  Ada.  This  course  is  not  required,  but  it  has 
gained  great  popularity  among  our  students  because 
manv  of  our  graduates  have  obtained  good  jobs  due 
to  their  knowledge  ot  Ada,  and  also  because  the 
students  have  a  sense  of  excitement  and  enthusiasm 
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w ;  ■  i  :  «'■  !K  i  wit!,  a  m*w  language  that  promises  to 

:mvi-  a  major  imp.ic  t  on  t  !u-  world  ot  coniput  i  m>*  . 

Most  students  taking  this  course  have  had  a 

■  su  vt-ar  course  in  PL/C.  Nevertheless,  thev  havr 
limited  experience  in  developing  systems,  hence 
tlio  approach  used  in  this  course  has  been  similar 
to  the  one  used  in  the  Technical  Level  Course 
developed  for  Fort  Monmouth.  In  fact,  the  first 
semester  has  bee;,  the  testing  ground  tor  much  of 
the  Iechnical  Course.  Topics  covered  in  the  course 
include:  I/O,  Predefined  types.  Compilation  Units, 
Procedures  and  Functions,  Packages,  Knumerat ion 
Ivpes,  Arrays,  Records,  Scope  and  Visibility  and 
Access  ivpes.  In  the  second  semester,  currently 

in  progress,  the  student fs  point  o!  view  is  shitt¬ 
ed  t  torn  being  a  user  ot  packages  toward  becoming 

■  designer  o!  packages.  The  student  is  introduced 
to  some  ot  the  advanced  concepts  of  Ada  adopted 

the  Fort  Monmouth  Professional  Course,  such 
1 '•  Private  Types,  Exceptions,  Discriminated 
h'i'i'n!  Types,  Generics  and  Tasking. 

1 .  Si  I  FTVARF  F.NG  I NF.KR I  NO 

Sort ware  Engineering  I,  II  are  senior  elec¬ 
tive-.  in  our  computer  science  curriculum.  Most  of 
t be  students  in  these  courses  have  had  at  least 
course  in  the  Ada  language.  Therefore,  in 
s.grware  Eng  ineer  i  ng  I,  we  use  concepts  .and  tech¬ 
niques  :r»c,  Ada-i  .jmp.jL  i hi e  and/or  Ada  h«ised  rneth- 
v’dv  ■  ,'^ies  such  as  SAD  (Systems  Analysis  and  De- 
i  gn )  *  ,  the  Jackson  Method*"  and  CORF,  (Controlled 
Requirement  Methodology)  as  well  as  the  Intro¬ 
duction  ot  Program  Design  Language  concepts  and 
techniques.  Also  covered  in  this  course  are 
i oncept  s  such  as  top-down  design,  modularity, 
data  abstraction  and  information  hiding.  These 
are  implemented  using  Ada  constructs  such  as 
packages,  private  tvpes,  separate  compilation  and 
prog r am  1  i h r a  r  i e s . 

A  class  project  is  required  in  Software 
Engineering  I.  This  past  semester,  the  project 
was  based  on  the  real-time,  embedded  Cardiac 
Treatment  system  discussed  in  Downs  and  Goldsack  . 
The  system  was  studied  at  the  requirements  level, 
using  the  CORE  methodology  to  specify  the  require¬ 
ments  of  the  system. 

In  Software  Engineering  II,  currently  in 
progress,  the  thrust  is  to  design  the  system 
modules  using  Ada.  Small  teams  of  students  will 
design  each  module.  Then  the  system  modules  will 
be  integrated  into  an  Ada  program  library. 

■*.  SYSTEMS  PROGRAMMING  COURSE 

This  course  is  intended  to  introduce  stu¬ 
dents  to  the  characteristics  of  system  software. 

The  current  text  is  hv  Welsh  and  McKeag*4.  Stu¬ 
dents  are  not  required  to  implement  the  results 
"!  their  work,  hut  rather  concentrate  on  design 
through  -ase  studies.  By  going  through  the 
Uvelopment  a  compiler  fo*  a  subset  of  Pascal, 
ind  hv  const ru«  ting  a  small  operating  system, 
students  gain  an  understand ing  of  systems  pro¬ 
gramming  concerns  and  methodologies. 


Sv»i  «T;  ;*«■-.  i  ,  :i  Langua. .  :  ’  .if  .  :  • 

ot  ; 1 .  i  v  r.i  I'f  -i ,  ti.r.s,  ;  i  ■■*:.!.  ,  :  !STi.  r.  : 

generic'-.  Student  .  in-  t  *  :.c 

modular  dec  ompo-.  it  j  inr  :  '  ;  nt! 

components  and  t  .»  pav  .  !  i !  l  .-at  i . 
laces  with  other  *  om;  -■ . 

S  V  1  S  I  1  1  Ni  •  FACT  I  i'Y  i  i  HR  S  r 

In.  tiie  summer  •  '  «  nr.  ]  i :  y.-:  *; 

*•!  the  Protessional  *  .  ;r  se  wa  .  given  dr. 

Caver  I v  to  group  .•:  :  a.  .  t  •.  :  i,c  vi  r  t !  - 

domi  nant  i  v  h  I  a<  r  .  o  i  i  ri'.c  • ,  sud  t  ■  .!•  e.  :  cult.. 

Hi  is  summt  r  we  are  >'t:,-ti:i.  an.  Instirut  ••  !  r 
college  iiltv  wit!:  a  o:rri.  bu-.ed  I 

Plot  ess  i  Ojla  !  oUTSi-  deVe  1  opt  d  tor  F-o't  Monmouth. 
Attendees  cm  t  t  to  ia-.eivi  cr.ulu.it  e  credit. 

LOU  I PMKN 1 

So  i.ir,  1 1  1  Ada  programs  developed  hi  eur 
students  havi  been  run  under  tin  New  Yotr.  Ur.  i  vet  - 
sity  Ada /Ed  interpreter  running  er  a  VAX.  ln.it  i- 
aily,  we  did  not  have  our  own  VAX,  but  ! -'itunat  e  1  v 
the  Rutgers  University  Computer  (enter  in  Newark 
allowed  us  tv'  use  their  VAX,  thus  our  student-, 
have  alwavs  been  able  to  get  hands-on  e>.p,  j  u  :n  .  . 
In  19rti,  as  a  result  our  i  <«nt  ra>  t  with  F<rt 
Monmoutn,  we  were  able  to  <bt  iin  ir  own  VAX- 
1  1  /7H0  ,  and  t  V'  set  up  an  Ada  1  ei  i.no  1  ug.  Cent  c  r  . 

We  are  inrreiUiv  using  tile  validated  Ve  i  ■•.  i  or,  -oi 
the  Ada/Ed  i  nterpret  er .  Ada/F.d  has  hr:i  inv  i!,:- 
able  in  enabling  us,  along  with  mate*  t  > 

•gain  invaluable  experience  in  using.  Ada.  rout 
it,  the  use  ot  Ada  would  not  be  as  idvain  ed  u.  •  it 
is  today.  Unf or L unat e 1 v ,  Adi/Ld  has  some  :n;.r 
shortcomings  -  it  consumes  enormous  resuir.es  and 
it  is  verv  slow,  both  in  c  orr.pi  lat  ion  and  in  exe¬ 
cution.  As  ot  tin's  writing,  we  won  making  ;  I  .un¬ 
to  acquire  the  TeleSott  compiler.  H-  pe  !  u  1  1  v  ,  it 
will  enable  students  to  run  large  programs  in  a 
more  reasonable  time  trame. 

Ada  TLCHNUlxV.Y  CENTER 

One  of  the  purposes  of  the  center  is  n  act 
.is  a  friendly  site  tor  industry  and  academe  and 
to  help  potential  Ada  users  get  started  with.  Ada. 
As  already  mentioned,  for  the  summer  ot  we 

are  ottering  an  Institute  for  college  faculty. 
Furthermore,  we  have  already  developed  a  liason 
with  a  number  of  local  companies,  and  we  are 
exploring  various  mutually  benefici.il  ventures. 

It  is  too  early  to  report  any  results  at  this  time 

FUTURE  PLANS 

The  trend  today  is  toward  the  development 
of  complex  computer  systems  and  large  programs. 
Yet,  manv  introductory  text  hooks  still  deal  with 
basically  the  .same  .set  of  problems  and  procedures 
that  they  did  ten  years  ago.  There  may  be  a  few 
more  commentaries  on  structured  programming  or 
top-down  design,  but  basically,  these  texts  still 
deal  with  what  might  be  called  "programming  in 
the  small."  That  is,  thev  deal  with  problems 
that  are  readily  solvable  at  the  lowest  level  of 
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’  .  r  in  it  \  «•  I oprr.ent  .  How  do  wo  get  undergraduate 
t  - '  etuullv  bu  i  1  d  and  implement  large 
■o.  Mor.s  in  some  reasonable  time  frame?  One  way 
i  *.  ;  nrovide  them  with  suitable  building  blocks, 
r.d  an  env i ronmer.t  conducive  to  assembly  and 

'tin.:.  A-J.i  has  many  features  that  make  it  suit- 
■.:-le  :  r  use  as  the  language  of  choice  for  "pro- 
cranmir  i.:  in  t  lie  large.”  If  Ada  is  required  early 
in  a  -tudent’s  computer  education,  the  student  can 
-•:>  uJ  mur<  time  in  desi  cuing  and  implementing  real¬ 
ist  i<  -''.stems  without  having  to  learn  a  new  lan- 
mace  for  each  v<>mputer  science  course,  just  be- 
i.  ause  t  lit-*  inabilities  of  previously  studied 
languages  are  inadequate.  The  catch,  of  course, 
is  to  provide  the  building  blocks.  They  need  to 
i-  reasonable  well  documented  and  debugged  and 
there  needs  to  be  a  fairly  large  number  of  such 
h  i  is.  U’hilf  mane  texts  preach  top-down  designs, 
thev  do  t  h  i in  the  context  of  programming  in  the 
small,  it  is  a  challenge  to  computer  science 
.daitors  to  produce  educational  materials  that 
will  reverse  this  trend  and  enable  students  to 
program,  in  the  large. 
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■.i«  <0  t_ r'i-  t«if  iCrtue'  »t 

Tactical  Conpiyt'-T 
t  u r  t  Monm.au  t  n ,  N ) , 


• J  r  Cj^erjtiiUJ  M)iJ 

:•  Pi^L  Jl  i-  ill/  BlaCK  U.'jilttjt* 
f  UlCvlJt's  intensive  Mtjis 

>  or  toe^e  i.  ui  iMjt';..  Jnl  , 

•  * 1  ir.'  Cfot  eSSUTS  *itn  u  tr¬ 

ie  : n..:.. j. u >  A/jd  within  their 

.-.j*  !  1'  u  i  ini  <ib  At  n  i  dd  ..  ,• 

.U-i'-'-L  -jt  U’fenh.e  research 

fr •  i  r lues  UK  ;.'i O'.i 'in  ihj 

issues  dun  i: iL-if'.-t  i< iu 
hiring  trie  course. 


..  .‘t.  ■i-t-i  UriiviTsity 

/. .  Hiji:  Ji : i  ijr live  r Ity 

>.  '..neyhey  Slate  university 

M^nplun  Inst  it  it tJ 
:  .  Mi  - 1  luntn  t.  i.i j  j-ge 

o.  North  L^ruijf.a  A4 ’  state  university 

o.  Pruiri*-*  vie*  university 


Section  i 
INTRODUCTION 

Uw  nr.*-;  is  ini  mom: mg  e-.t  i i>- iy  ne* 

i  .  I  f?rrectlvv  Ady  i  'j:.;  v;t  tw^r-.1 

ienl  i..eut.t-i r  u  uf.  the  MJrj  j-ungu  jge  unu 
1  ]  >.  it  et  ;v  i  runi  It* ut  ■  I  he  AU-I 

.  r,  Mir.'  3/sLem.) .  r'leseut  dut ivi lies  iuo  lo-Je 

■  :  «'■  1  g^i'1  ;  i  ■  r*  ;  .  V  t.  .*  lUL  i  >  jM...  I  r  ‘ : -rs  j  J  •  Uj  J 

1 1>.  .  t  i  o:  r  or  use  in  .,:‘,njnni.; t Ion 

•«iU.  *•:■»  a-s  l  j;  ueve  1  :.•{.■  i  f  i(;  euJ  I  i  -ji 

i . i *  ,r  .*.»»•  i r •  Ann  i  raining  r>c r.  ivities. 

jH'J.,,,  1 1  ’si  I  unc.-;  t,« ;  in 

r  v  4  ;■  }  m  ;  i  1  tu  uc  •  iJeni  >i  t ; .  r  /ugh 

i1 .  1 1  v  1 1  i j  j r  i.i  ,  tn*'  tNlALS  SuW-el  Pi  Uv3I\ii'-. 
*‘-n  'J  "U-  ,  ;  ■  r .  -  J  r  W.is  I)  to  t  I.i.- let 

m  t-.i  rise  tu  i  i" 1 1  e°>b'.’  r  s  *  ion>  .i.  r.-.s  the 

...  s'  -  \  )  U  Cot  •  *  1  -  j  ‘  ii‘rj  l.*'lf.1l  tu  I  '  !  t.  I  "i  Jl .  ► '  Mill 
:  ".t' :  cjtTic  -luro  ;  t  L.  L  iovije  i  '.■■ji'  *- 

i*  re.e.jr.-.  •  *.  »*  Uen-ti  u'vi -t  i*  sot  er. 

1 . x  BaCkgroung 


si)eim«in  J:  i  iversity 

j.  ■.  HjS«>'»;,h*e  Inst  i  L  Jte 

1  i  .  Y*  : v J •  Jst  s.A1  i  •.  "  '  1  V’JI  S  i  t  y 

» .  Uf.ivnt  .  1 1  y  •.  t  k.;i  rip  i  t  ,JI' 

U'H  .  .I  r>e  S’U.O.I  ...  Ait  r  u  tfcMm  r’XfctClse. 

Tne  ...•rigiucii  pidn  v»js  to  use  jn  Intersection 
v.<y '  t  n.  i  *  j  >  >t  .'  *rn  \  i  i  .us  i  c  St  on  1  i  O'  ■  t )  -i  s  t '  >e 
exercise.  Oue  to  the  gels  vs  causec.  oy  Aud/ty 
thf;  ays  a  Jr-  not.  .at.,  i.'  to  CC'OO  any  i  tie>-ing  anu 
rogiif‘stevi  that  the  gicup  u  roc  lent  be  reauceo  in 

.u'Viex  ity.  rr'-retbL-  ,  UCu  ’eCt  iteO  d 

toisetiuli  gar;:t-  witti  cert-.iir.  refinements: 

i  .  he  ’  ‘  4  ■  t  t  '■  ifi.f  •  5  ill  JvV O; ) . 

;  1  M  pi.iyer  a JV^rc^d  ;.  '»t.*  vJV 

'•jtnner  of  bases  inUicateC  .  \  the 

touole,  *’  7i.-h  player  a',:vances 
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i.'ir  i  ;t 


it;nninaU 


n:  -.1.-1^:.-  w.JS  ..liviijfri;  into  ?  IrjmS 

«■ .  jt  ,  -a  mc'n.oer^  «nu  - 

v  ','y,  T  r tr.jj;’i5  w<r*re  qivtn  the  auJvu 
•  it.Ljii  ,jfuj  jiven  uue  wee*  to  prouuce  the 


".t  the  r-r  i;j  of  tne  week,  the  teams 
i.;*:  ;  '..  he.  A  crwiqe  in  the 

.»  r i r  ii  ..it  i  jr i  _,f  the  prooiem  was  announced.  The 
aj,  «:>.:! i  0  hit  occur*,  eacn  player 

;  ho*  dovance  the  humoer  of  hoses 

I'  r.'  i  i\  j  pnJ ijur.  'turnur-i  rjenerator.  tiden 
•  »fi  Z‘. •  h f -  :  thoir  view  jf  how  easy  ur 
h*  *  i  j  i  *.  *.  :»•;  .  ..it  another  tejit  was  to  chaoue 
.  .  i  i  /it  r  f.r  ...■i.ihije  in  the  specification. 


it  t-jj*  -  ih;  tedfr  only  1  Gay  to  mouify  the 
.» >  .  I  he  tor  the  ,hr  rt  time  requires 

w  iv  he...ju  .w:  e .:icn  team's  cooe  was  well 

j  i •  i r  1  -a  •  •  Lean  n»iu  only  one  moauie, 

... ..h.nc  ioeht.ji  iy  ..aiieo  advance  Conner,  which 


1.2  Facilities 


••ii, nr, i J  jth  Lfllege,  west  Lung  Branch,  New 
■eiv'y,  j.hoer  contract  to  Cl.MmlS,  proviaea  the 
.  Las.  >:..■<  'jn  ‘sc  Lillies,  class  was  conducted  each 
•  i.r,  h-  ij'-ii-.'ih;  >i ju,  a,.;o,Ti  ffL:s.  r.ion  student  hah 
hi-,/ her  jwh  w^r k  tdde  witr.  a  vT-100  Terminal 

li'irc.f  J  t  -  J  '<***  ii  //tie  with  -iuli/ca  ihataileiJ. 

ie  Aia  provided  uy  t  wvicnics  Research 

..i1  u;  ■  Jey.-ippi'ir’ht  .Jomf'.n'X] 


rtij.iitinh.il  lecture  h a  1  * s  were  provided  oy 
.jo  re..jui i h-r  ninjst  speakers. 


1.3  Guest  Speakers 

dies':  sneakers  were  invited  to  participate 
h.  f'igh*i;ni,  >’rtain  ar--i^  ... f  tee  lcinyuoo-1.  Trie 
vie  a  ke  is  j'.  *.  tneii  respective  topics  were  <■ 


•' j*.  :...r  i.  + 

r^frci>2  'if'ivPi'ii' 


•emeries 
T  3  S*  i  fHj 


Proposal  *ritif*j 


^ac^ine  Pec  reseat  at  io*' 
Specifications 


,enencs 

iompiler  Implementation 


Jest ract ion 

Suiliinp  _arqe  te^-s 


ii  t.-i  1  r.qui !en* 


bee  t  i  on  2 

PEDAGOGICAL  ISSUES 


;n  t  i  .jfscrii  <■ 

r.ii  s**rj  -jirinc  *-h>- 


2.1  Input/Output  (I/O) 

This  issue  centers  aiuunr:  no.  and  w-,e- 
to  teach  1/0  in  Aaa.  In  Aua,  I/O  c:  i~.it  Ives 
me  mued  as  port  of  the  lunges  "in  m  p/' ^  1  a 
Text  Id.  Too  basic  file  man,  .;~Tv--'t  =tpat  I  i  it  :•• 
(e.g.  file  creation,  open,  -.nq  -1  :.se;  in 
provided  oy  sutiprograms  in  the  ^>,01  .irn: 

accessed  by  simple  procecure  jivi  *'uicti 
fills.  However,  the  actual  procedures  ti.  ettai- 
inpit  ana  produce  output  are  type  specif  i 
su'iie  are  svailatle  Py  a  siriple  ;  t  'n c . r ^  ; 

function  call,  while  others  ire  e<rCe iota  wit'in 
•Teneric  packages.  for  exju.ple,  for  t 
Character  and  String,  I/O  is  provided  cy  '.>• 

overloaded  procedures  del  arc  o./ , 

(Additionally  Put  Line  is  provided  f..r  Strir>n) . 
ij  utili/F  these  facilities  reciuires  a  si-’in.-. 
procedure  call  anu  can  be  taught  early  in  the 

course  wnen  "with"iny  a  pacKace  is  introduce.!. 
To  perform  I/O  on  the  other  types  -  soeci final Iv 
the  class  of  integer,  real,  -iOd  enuneidt  i :  r 
types  -  requires  instantiation  :f  cenerit 
puCKages  located  in  Text  1„. 

If  a  top  cc»n  ap.'proach  tc  t.  a,mi  a;:;.,  is 
■utilized,  the  with  clause  is  introduced  a r  1 , 
anu  therefore  "with  Text  10;"  becomes  J"-  e.i  ■, 
clause  for  students  tj  write  ana  they  , 
perforn.  character  ana  string  ;/o  .itnout  sir  i 
difficulty.  Hut  fur  the  student  tc  nerforn,  ;/u 
or.  other  types,  ever  inteoer,  seouire-i  t-.- 
introduction  of  aenerics  and  rme  rjnr.e;  *  .  * 

ifl.St  a1  1 1 1  a  t  i 'JI 1 . 

It  is  unceslrat'le  tc  int uuuce  gen»'ri.  •• 
early  in  toe  course  as  the  subject  is  couple 
and  requires  time  tc  teach  tnorjwjr.ly 
properly.  On  tf«e  other  nano  tc  dive  2  liner,  c-f 
code  to  a  -student  and  tell  nin  "Put  f"is  cj  in¬ 
here.  It  worws.  This  topic  wiil  be  cevet" c 

later  in  the  course. ",  is  in  .general  not  fie 
pest  pedagogical  levice.  dot  this  is  exact  iv 

what  you  must  co  in  Aqa  to  allow  the  student  L 
perform  i/o  rjn  those  types.  The  student  ""c.-t  be 
told  to  write  the  following  instantiation  whl.e 
wiil  a  1  Low  I /Pi  on  the  predefined  type  Inteqe: 
with  little  or  no  ex;  ia-iat  ion  as  to  what  5  a 
transpiring. 

package  My  integer  it)  is  now  Integer  If  ..  litege;  ; 

cne  temporary  .-ci  it icn,  tc  f  1  .  ci'.enr.,  : 
to  provide  a  "Duffer"  between  tne  stuopnf. s  ,  ■ 
Text  ll.1.  This  was  done  by  Lie.it.i'u:  ,  gai  v.  , 

Called  Easy__l'i,  wt’ich  inclugea  fhy,  ■  ■  ■  ■  ■-.  y 

instantiations  fir  the  predefine,;  types  0  in, 
i,ih  juaye,  i.-.  integer,  -inyt,  and  nucie..-' ,  n  ■ 
reri.j-iing  i,;at:ons  h:i  Pfi,.r-ic|e;  a-"',  -  r  r  1 

i/'J.  i'y  1  iny  the  st.i  fc,  ts  tc 
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<  ■'  f : :  i ! '  tmt  i ic  Question  wh 

..it.  i .  i  '  :  .v  .1  i  p*.trf  1 1:  i 
,  :i  t  i;  i..;  1  .  .■  i  i  wi  *1  ir  ;• 


2 . }  Reagaoility 


•  ■  ‘  a:  it--.  die  taiu.  Which  is  easier  to 


v'L'-blUt 


Ait-  T  h  X  T _ I C  ;  LSI  TtXT_it; 

rful. t. i.t hp  t.  xeef,..  t  t't't'O',, 


--d-Os  (.11  ef* t  J ufvb  'it  Li  SSAKV  f-LAiif  it  t-i  e-. 


I  -  '  .If- 4.  tKiAV"); 


-V  (.  A:  ;  ...  Tf-cLi  bTATtMtNTS 

:  tfv-t.l  jaM-V-M.; 


VEPbICN  2 


.(.•••  r  i.  •  •  f->.raec  it  to  its  fn: 

tp-r  /  .  :rt.vi"'.  ;  ,  ■  •  iorpc. .  LOOf-S  an* 

extra  tion  nar  'if  rs  '  ■  ret  Peer  cove  ret  st  tni: 

point  ir  tire.  T~e  ft.  :jcv>irO  7  versions  if  coat 

I .  r it:  tr-eTsef  vf.'s  very  "’ioely  tr  a  discussion  cf: 

J.  Jr stant istioe  cf  Text  ID  ceneri' 
cackaaes.  wher  it  is  "recjirec:  an* 

worn  it  is  riot  recuirec. 

2.  Cover  in*;  all  choices  in  case  statemer" 
alternatives. 

?.  Proper  choices  for  i certifiers. 

A.  Case  statement  versus  if  statement. 

5.  Modifiability.  teach  prccrar  i( 

easier  to  mnoify?  Version  7  reouire: 
no  changes  to  its  executable  cede. 

The  results  cf  such  a  ciscussior  wen 
remarkable  anc  a  oeticeabie  chance  ir.  res' 
students'  code  took  place  after  t*-i«  ci secssier . 


I*,  a*  y  pours*,  it  js  important  to 

res-.  iM.-ert.iti'.r  jet:  ••  f  upper  and  lower 

oav:  tr.  enhance  readability  nf  Add  code.  For 
r  'j'V.-r-f  this  i-  a  very  difficult 


end  ( .xerc  i  selt : 


Vt.KSIL-N  1. 


Sect  jo,- 


'i  T  ex  t  I L  j  use  T t:  x  t  I  t.  j 
:eaure  Lx; jane  is 


Character ; 


:n  —  -  arv : 
•.‘M  (Ch); 


(  ACTUAL  ) 
STUDENT 
V  CODE  j 


duing  D'-.:.i.r-it;or> 
t  .-Upwind  :.T>rHnr«(  r- 


3.1  Parameters  of  Mode  In 


f-ut  ("Lcit"); 


Put  ("List"); 

■  1  > if  Ch  =  ' r '  r her. 

Put  ("Pel;'1 
e I ; .  i f  :  '  =  'P '  then 
Put  ("Print"); 
c-isif  Ch  -  then 
Put  ("Quit"); 


The  nonce;  t  «:f  -  ;  C  -r.r.r 

representing  cate  flowing  it  U  a  ru  ctii 
not  present  ary  pr  criers  fcr  t*e 

Adcitionaily ,  when  augrertec  r  ,  a  circus 
■now  tin  in  paran-;elcT  :ets  -as  a  .  a  cat  . r  - 
therefore  is  net  modi  fieri  e,  student s  rr. 
neacs  iri  understanding.  Hcwtvs r,  w-n- 
tne  concerts  are  lost  am  attempts  are  : 
assign  values  tt  tt  ese  parameters  anr;  t 
them  as  actuals  tc  subprograms  whose 
parameters  are  ot  mode  i-  out  or  rut 

example,  cne  student  harj  the  following  ( 

rep resent  an  operi  procedure: 


Put  ( "Improper  Input " ) ; 
“re  if; 


witfi  Text  Ic;  use  Text  IC; 

procedure  !->_Lpen  (  fame  :  in  f  i  1  e _ T . t e ,  is 

begin  —  My_Lper 

crease  ('.a'se,  ‘,ut_Ki.e,  "Lata-dat'D; 
end  My  open; 
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tr  Text  10;  use  Text  10; 
OCeULTt-  Expend  Command  is 


type  Input_Character_Type  is  \ 

( L ,  ,  h  ,  (-■ ,  i. ; ;  \ 

type  E xpancec_Commanri  T ype  is 
(Lcit,  ;ist,  Help,  rri>-t,  Cult); 


ACTUAL \ 
STUDENT 
,  CODE  / 


Irput_Character 
r  xpar  ced_t  .t-mrrani; 
Position 


I nput_Charac  te  r  T  ype ; 
o  x;  :anr.ed_Commantj_Type ; 
Integer ; 


Pa.-Kaae  iripuf j".f.&racter_IC  is 
new  inur-t-ratior  _ie  ( lnput_Charaeter_Type) ; 
paCKoce  h xpannec  Conmar ,c  I C  is 
new  f  numeration  it  (t  xpat icK;CJEon»r.anu  T ype ) 
use  irput_U  aractei_i'..; 
use  expanded  Conn  air!  It; 

sir  --  Expand  t onmnne 


hare  is  a  parameter  of  ~cce  tr:: 

v-ei  store  may  net  te  moaifiec  ry  the  procedure, 
vet  tr.;  procedure  passes  this  parameter  •=' 
actual  parameter  tc  procecure  Create  i^  Te>-_; 
whose  formal  parameter  is  cf  Meet  ir  c.t .  ’•  . 

error  was  detected  at  compile  time,  ay  st.?*r  :■ 
the  following  compilation  listing. 


1  with  Text_lC;  use  Text_I0; 

2  procedure  My  Cpeh  (  Name  ;  in  Fi'e_Ty:  m-’, 

3 

<j  begin  —  My  Open 

o  Create  (Name,  Cut_File,  "lata. cat"); 

***  hematic  Error;  inout  actual  parameter  no . 
in  tail  is  not  a  variable  (LKm  t.4.1) 

b  end  My_L|.up;  /.ACTUAL 

y  (student 

i  translation  error  c.et.er.tt a  V  code 

Transiaticn  time:  22  seconds  n - f 


.2  Discriminants  with  Default  Values 


Adair,  concef  tusl  unders .tancini:  cf 

oust  root  is  suite  distinct  from  correct 

join;;  r.  cor. struct.  “  common  error  encount  er, 
■  exempli  fil'd  by  tii-  to  Hewing  code: 
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M.  Susan  Richnan 


Tfu-  Penns  v  1  van  ia  State  Un  i  vers  i  t  v ,  Tin-  i  t  • » 1  campus 

Mi ild  let  own,  I* A  170  >7 


in  di1  si  filing  an  Ada  program:::  i  ng  I'uiirso 
within  -"it  .-o  1  1  and  un  iver  s  i  t  i  os ,  one  ot  the 

first  i  ssiir  s  wo  must  confront  is  the  level  id 
expertise  we  shall  at  as  prerequisite  to  t  ho 
.our.se.  Ada  is  a  wrv  rich  and  complex  language. 
Mas:  tlio  student  li  iv-  exper  i ence  wi  I  li  some  other 
ni.-h  eider  language  in  .  r-U  r  t"  appreciate  Ada 7 

7h. . maker  ..an  tends  that  programm  i  ng  in  Ada  .an 

he  tan /.hi  i  :i  a  no  an  ingf  a  !  wav  to  t'ne  noophvto 
and,  in  rant,  there  are  decided  advantages 
inherent  in  learning  Ada  as  a  lirst  language. 

•■■.jine  -aiggest  ions  are  offered  tor  coping  with  the 
si/e  i  mi  .•»»••!  nl  ex  itv  of  Ada. 

V 

\  vu  t'oduv  t  iou 

The  AdaK  programming  language  is  named  for 
Vug:;  st  .i  Ada  t  1 M  I 'd- 1 8  52)  ,  Countess  of  Lovelace, 

•  laugh:  e*'  or  the  l.nglish  poet.  Lord  Bvron  and 
/  eue !'  i  i  !  considered  to  be  the  world's  first 
.  omp  ;ter  pr '  ./rammer  . 

Adt  was  developed  under  the  auspices  of  the 
i  nit-d  States  Departnu-tit  'd  Defense  (DoD)  in 
i  *.■  spoil  so  to  the  "software  crisis."  Bv  the  early 
! ■  •  m  id  -  1970s,  programming  languages  used  within 
1 1 .  •.  ■  Doll  pt  o  I  i :  t-rat  ed ;  estimates  range  from  +50  to 
iVid  languages  and  incompatible  dialects.  Studies 
;»!'** :  e  •  toil  tii.it  enormous  savings  would  be  realized 
i:  the  iJo|j  used  ope  common  high  order  language  for 
i.i  o»  its  appl icat ions.  Requirements  were  de- 

*  ined  It  a  language  to  serve  this  purpose,  as 
d»-s.  r  i  Led  in  the  Ada  Language  Reference  Manual: 

Over  i! i ,  these  requirements  cal  1  lor  a 
language  with  considerable  expressive 
vou*-t  .eyering  a  wide  uppliiation  domain. 

As  a  result  t!ie  language  includes  facili¬ 
ties  of  f  «.  ■  r  i  ■  d  hv  i  Iussi.ul  languages  such 
is  I’as,  .tl  as  we  t  i  as  lacilities  ot  t  en 
:  •  !i  1  in  spe  iali/ed  1  atijMiages . 

7  ;.u'-  the  language  is  a  modern  ulgo- 
ritumi  language  with  t  lie  usual  control 
st  i  :■  ’cir*  and  with  the  abilitv  t. 
del  i:n-  t  vpes  inf  subprograms.  It  i  i  s-  ■ 

-ei'.s.s  the  need  ‘  or  :•!.;<  in  I  a  r  i  l  v,  wherebv 
•  fat  i.  f  vpes,  and  subprograms  .an  h* 

;U'  ki,;>"l.  It  treats  modularity  in  the 
phvsi-  if  Sense  IS  Well,  with  i  t  !■  1  i  it*/ 
t  i  support  sepu  r  if  e  omp  i  i at  i  on . 

H 

Ada  is  a  registered  trademark  ■>!  the  1  .S.  f.ov.  run. 


In  addition  to  l  iieSe  aspects,  the 
language  covers  real-time  programming, 
with  la-,  i  lilies  to  model  parallel  tasks 
and  to  handle  exemptions.  It  a  1  so 
covers  systems  programming;  this  requires 
precise  control  over  the  representat ion 
of  data  and  assess  to  sv.st em-d ependent 
properties.  Final Iv,  both  app I i ca t  i on- 
level  and  machine  level  input -on t pu t  are 
dot’  ined  .  * 

In  order  to  meet  all  those  requirement's,  Ada  had 
to  be  a  verv  lutve  and  complex  language,  indeed. 

The  features  which  make  Ada  su-h  a  rich  and 
powerful  language  appear,  on  the  sari. tee,  to  argue 
against  teaching  Ada  as  t  lie  student's  first 
programming  language.  In  :.i,  t,  most  texts  written 
on  Ada  are  aimed  at.  the  "exper  i  enc  ed  programmer  . " 
Vet  the  possibility  of  teaching.  Ada  to  the  un¬ 
initiated  deserves  careful  eons iderat i on. 

A  number  of  Ada's  features,  while  inc  c-rporut  e. 
into  the  language  because  of  their  usefulness  in 
complex  systems  rather  than  tor  pedagogical 
reasons,  may  actually  significantly  benefit  the 
novice  programmer.  Those  features  will  he  con¬ 
sidered  without  regard  to  whether  or  not,  or  in 
what  ways,  Ada  may  be  a  "better"  language  than 
other  languages. 


1  dent i !  i ers 

In  the  context  ot  powerful  tools,  t he  matter 
ot  identifiers  seems  almost  trivial,  vet  it  can  he 
of  great  importance.  The  Ada  philosophy  empha¬ 
sizes  that  it  is  more  important  to  !u  able  to  read, 
and  understand  a  program  than  to  he  able  to  write 
the  program  quieklv.  The  program,  it  useful,  will 
be  read  nanv  times,  but  wj  it  ten  only  once.  While 
tin1  purpose  of  this  ohjei  Live  is  to  improve  tin- 
ma  int  a  i  nah  i  1  i  t  v  ot  sot  iwarr,  i  long-term  c.oa  i  , 
read.ibi  1  i  t  v  is  also  vital  to  the  student.  It  <  a  n  — 
not  he  assumed  that  a  beginning  student  will 
naturally  b.  able  to  read  and  under  si  .and  his  own 
program . 

When  i  student  begins  to  write  .ode,  he 
shot!  id  hav»  .i  •  lear  mental  image  o{  t  he  log  leal 
striii  tiirt  o!  Ilfs  program.  At  tubed  to  this 

Ada  :  i n i  Pr  oc  rum  nt  t  i .  »■ . 
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r uc  t  ii  ro 


art-  various  entities  (data  types, 
variables,  suhprog  rams ,  etc.).  If  t  licsi*  ent  it  ies 
irv  given  names  that  art'  strone.lv  sueggest  iv,-  of 
t  ho  r-'lt'S  t  lu-v  p !  ,tv ,  then  t  ho  stru  tart-,  with 
objects  atcai  ht-if,  becomes  a  unit  it'd  whole.  I-'  the 
lorn  o'.  tlu-  idenlit  iers  is  severolv  rrs!  rii  ti’ii, 
names  he.onu-  cryptic,  art-  on  1  v  vagm-lv  sni^osl  ivo, 
anti  I'oniusf  the  student’s  ^lont.il  pi.  Inn-  rather 
than  reinforce  it. 


starts  writ  in.-  iv;:...  J  iate  I  v,  mud  i !  v  inr  oid  e!:asi 
as  tin-  si '  1  u  t  i  i  'ti  pi'  •>',  ti'SM’S  .  Thor-  si  oh  *.  v  pi  in:;*-,; 
programs  a  I  so  t.^c  loss  t  ime  (  In-  1  >  :>  i  i  n  .•  planning 
t  i to  h«-  developed  and  requir-  loss  ft  r:::ina) 
(■..a  ss  time  (an  im;>or  t  an !  .  ons  i  der*.  .■ !  i  ■  ■  m  in  J  hi‘S« 
iiavs  w!umi  •  ow  .■■■>*:- put  at  ion  .  out  or  ’  have  enough 
t  ,  rm i na l a  1 .  So  Ada  cillon  i-s  a  stri.l  d  i inline 
that  results  in  improved  dcsi.-.n  pract  i  wit  a 

i  nsi’ii  d  ia  t  o  horn-!  it  iu  tin-  student  . 


In  Ada,  the  length  o:  an  identit  it-r  is  re¬ 
st  riot  od  >  'ii  I  v  bv  t  h  j  1  eng.th  o!'  line.  Consequent  I  y, 
the  n.une  of  a  data  oh  loot  or  lunct  ion  or  package 
..in  be  chosen  to  <  leirlv  ret  loot  the  nature  ami 
roU>  nf  that  eti'  ity.  One  won’t  have  to  wonder 
whether  CM! ’MAT  fetors  to  COM  PUNT  NT  Of-’  MATRIX  or 
COMPLEX  MATR I X  or  COMPOUNDED  MATRICIDE  <«,- 
COMPLIMENTS  TO  THE  M/\I THE  0;  it  will  be  clear  ti¬ 
the  identifier  riiosen. 

In  choosing  identifiers,  learning  FORTRAN 
prior  to  learn  in-.:.  Ada  ran  be  a  disadvantage.  A 
triend  who  berate  a  skilled  FORTRAN  pr iy. rammer 
before  learning  Ada.  persisted  in  using  FORTRAN- 
I  ike  identifiers  in  his  Ada  code  —  terse  and 
crept  ic  —  apparent !v  sourest  ive  only  to  himself. 
This  habit  is  difficult  to  break  and  makes  the 
intentions  of  the  programmer  wnnecessar i l v 
obscure  to  the  reader,  even  when  tin-  reader  i-‘ 
the  programmer.  With  careful  choice  of  identi¬ 
fiers,  Ada  code  that  is  ready  to  be  compiled  can 
lu  read  almost  like  clear  English  prose. 


win  1  af  it  v 

Even  a  In  at  inn  ing  student  is  likelv  to  writ-- 
a  program  with  enough  comp  I  «;>.  i  t  v  to  mar-,  it  w-  r  ' 
whi!«-  to  subdivide  it  into  small  or,  mur«  man  i.-oab ; 
unit  that  can  hr  separatrl.-  drsic.nrd  i :n i  h*-  h-i. 
An  Ac. a  program  is  written  as  to! lows:  it  i- 

partitioned  into  logical  pieci-s.  «-a  -c.  dr.il  in. ■  wita 
sente  part  of  the  problem.  Tilts  part  it  i  nine 
(whicii,  of  course,  could  be  done  ill  a;  informal 
way  with  any  language),  when  coupled  with  the 
capability  for  separate  compilation  «■»  i-.,ch  •  in  it  , 
is  useful  to  the  student,  as  well  as  t>  the  ex¬ 
perienced  programmer.  Eacii  ot  t  lie  logical  units 
can  be  designed,  tin  a  checked  separately  bv  t  in- 
compiler  tor  logical  consistency  within  itsrl:  cici 
with  others  in  the  program.  This  permits  the 
student  to  concentrate  on  smaller  portion-  <d  the 
problem  at  one  time  and  to  handle  complexity  i-i  : 
more  reliable  and  et  5  icient  rn.mnej  . 


St  rung  Typing 

Ada  is  a  strongly  typed  language.  This  means 
tiiat  every  data  object  used  must  be  dei  lared  to 
be  .*1  .i  specific  tvpe,  either  pre-do!  tried  (  inte¬ 
ger,  i  lu.it,  or  character,  for  example)  or  user- 
defined  to  fit  the  particular  situation.  Further¬ 
more,  ea.h  object  must  be  used  in  a  manner 
consistent  with  its  type  .<>  that,  for  example,  one 
cannot  compare  men  to  women  it  they  have  been 
declared  to  be  ot  different  tvpes.  Usually, 
comparisons  of  different  kinds  of  data  objects, 
su.  h  as  distance  and  mass,  are  unintent iona I . 

Ada  actively  discourages  this  kind  nt  error.  If 
vou  really  are  misguided  and  want  to  compare  men 
i"d  women,  you  may  do  so  bv  making  your  intentions 
explicit.  You  can  declare  b-tii  men  and  women  to 
be  derived  types  of  another  people  tvpe  and  then 
compare  ttu;-.  after  doing  type  conversions.  But 
if  von  haven’t  made  your  intentions  clear, 
comparing  men  to  women  will  result  in  t he 
ompiler  saying  that  von  can  t  d>  that. 


Absl  r.u  i  ion. 

When  a  ?-t  udent  is  gra;piiip;  with  i  nr  •hie": 

!;e  ;-ia v  l  ecl  that  Me  must  understand  n-’St  -let  «i! 
t ' !  his  solution  i  k»t  ru.'Uires  o’  liie  lit  ,  t  x  «>  I 
how  variables  should  he  incremented,  and.  so  :ortu ) 
hot  ore  he  can  compose  the  c-»de.  Since  tlu  r<-  i  - 
limit  to  how  nanv  f.n  et  s  t  hv  pruble"^  the  min-.: 
can  handle  .it  oiu-  t  i”c,  this  an  lead  to  "blank 
page  paralvsis."  Ada  ell-  oil  t  a  .  s  dirt  dent 
approach. 

If  the  Student  feels  the  need  !•  !'  ‘i'jei  t  ■■ 
wiiicii  have  ef'tain  prunerf  ie-,  Ad  t  permits  hi-  t- 
i!e.  lari:  a  data  tvpe  with  tin  lie-  t-ssarv  pro  pi- ft  ies, 
without  specifying  the  details  •>:  t  i.<-  interna  i 
structure  at  that  lime.  1  h  i  ;  is  an  uhstru.  t  d.it  i 
type.  Ada  also  all-  ws  r  o»-  tic  ab*-a  r  i  t  i •  -u  ■" 
oper.it  ion:;,  tlu*  sepaiat  i  n  •  -!  *•  '  t  !ie  op*-:  it  i.  a  -; 

Jo  and  -.  t  liev  are  implemented.  At  tin  top  1  iVe! 
ot  design  the  st  ruct  m  i!  and  imp!  e-.ou!  it  tut 
Jit  ills  ate  in-el. .vint  m-i  -•v.-.et  ime  a; 

•'  i .  Jure. 


All  * » t  tlie  tvpi'  dec  1  ara  t  i  ons  ami  the  invi»lved 
Piles  as  so:  fated  with  them  an  be  rather  d.nmt  i  m: 
to  fji.  he.-  inn  ing  pr*>g  rammer  and  tedious  t .  *  anv- 
.  }iowey.*r,  the  student  b'-no!  its.  Wliv?  He 
is  toped  to  give  e  ireful  thought  t>'  the  design 
oi'i  Manning  ot  the  program  before  he  begins 
■  ding..  '-Todies  have  sfn-wn  that  the  pr* v rammer 
vii  j  in'/.  •  ?s  .  ie?  ,e  .■•?(•?•!  in  the  planning 
■  {  iges  ..p  pp'ble-  se|  v  ini’  write-,  pru-rams  with 
'  .  s.-r  st  1 1  i-m.i -nt  s  ,  .  *-m»-r  log.  i,  and.  greater 

.  i  ;eri  v  •  !;ar:  l  :  ■  :-r  1  ar»ts  ot  .1  student  who 


As  the  design  i i-  refined,  the  intirnul 
■>tru-  tores  and  related  . -per  rt  i 'Uis  ste  defined. 

I  t  s.  »n,  ■  ■  l  t  'aes.-  i  r  •  ■  quite  .  onp  i  *  x  ?  hev  i be 

iet  i lied  in  ii'i'"s  '‘I  s  inn  i e j- ,  hu?  'til!  absf  ra .  t  , 
t  vj  anti1,  ill  are  di  fined,  it:  the  i'i'Jc 

tvpes  tiiat  are  ;u  e--i  e*  i  tied  bv  tdh  lampitce.  1  lie 

-.i  i ;  • ; •  r  r  et  tin-,  stepwise  re?  i  f.'e?:*e  n!  is  vet  anottn-r 
w  iv  i  n  whii-is  Ada  assists  the  --indent  in  •-  impii- 
!  vim,*  .in*!  under  ,t  indite  t  be  problem. 
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Debugg  ijig. 

As  mu.  ii  as  Ada  cn-'ini rages  gooc.  de  sign 
; :  r .  i .  t  i  i  ,  - ,  tiTiifs  will  ui'cur.  Inlu-r  i  led  Iran 
:  .  i : .  a  1  i  -  tin.-  ph  i.  I  osophv  t  fiat  tin-  oat  a  slrurlnr»*.s 
rad  th,'  .i  1  gar  i  thins  should  be-  spe-.iti.ed  previsvly 
•  1  *.  .  *  t  I  ’v'  and  that  t  i  if  compMor  shouid  delect 
m  i!!\  err-rs  as  possible*  (  t  ypog  raph  i«a  l ,  syntax, 
in.'.'us  isli*:n*  ies,  etc.).  This  com;  •  i  lv- 
r  i  :t;  e  ■  d.-te  lion  is  greatly  preferable  to  r:r.  it  L  in,-, 
trier-  !>'  ivn.tin  until  ruit-l  i:m-  when  t  lu-v  art-  much 
•  ore  dit*.  icult  t  o  locate  and  more  t  ino-consum  in-,* 

»  ra.  .  .  Ada's  uhilitv  to  Jctei  t  nanv  errors, 

.•.a  !  v  *  :iii  an  t  om.i  t  it  .1 1  1  v  ,  relieves  the  student  «•! 
o  o*  the  burden  ot  program  e  her  king  and  helps 
u  it  i.  ■  !  or  i  no  complexity  of  the  language. 

•av.,-e  error.',  are  dole,  tod,  Ada  assists  the 
undent  in  H  iking  tlit*  net  ess.iry  changes, 
m.  dciaritv,  together  with  t  lie  rules  {or  so  ope  and 
■/  i  s  ;  l  \  \  t  v  o’.  variables  and  the  precisely  defined 

in!  err  a.  -  s  .  »  the  module,  wit.ii  earn  other,  pro- 
" i. ■ : 1 1  ■  hangt  in  «  ne  part  oj  the  program  from 

pr  j;- nt.it  i:vg  unprodi*',  -hie  effects  throughout 
tin  entire  program.  i'  a  rliange  is  made  to  a 
.  ai.ihte  within  one  subprogram,  ,inv  effort  out- 
.  i.le  that  subprogram  will  he  clearly  delineated 
t  hr an;.;:;  the  inter!. ire  of  that  unit  with  ether 
pr.'grar:  units.  There  should  be  no  unpleasant 
surprises  ten  lines  into  inether  subprogram.  So, 
if.  rorrer  t  i  on  o;  errors  is  not  tin-  monumental 
-  k  it  ran  be*in  a  mono  I  i  t  h  i  r  program,  with  the 
e;  *  e,  t  -  oi  mud  i  f  i  ra  t  i  cuts  rippling  throughout  the 
--n!  iiv  -,f  ru.  t  urr. 

1  •<d P.1. .h  -1  L  1  *: indjjj 

J  I is  i.-.  a  topi;  whirh  some  instructors  may 
hi-:'  t  •  ,  am!  •.  er  t  a  in  1  v  .an,  postpone  to  a  more 
i:-.-  m.  I  > •- : r :•  e  in  Ada.  But,  exception  handlers 
n:  hi  ’  :?ed  ,  >  •  1 1  an  e  1  ement  ury  level,  to  advantage.  J 

aii  errors  in  i  program  ran  be  detected 
fa  in.'  ■  i  1  a  t  i-.::.  Some  errors  o.  ■  ur  « *  n  I  y 
!ut  i  nr  j  til. il  exe  ut  ;  •  m  when  spe*  i!  i-n  data  values, 

.  ittie:  input  *  r  •  ai.  ulated,  result  in  an 
an*. mu  w.  ’'ituat  ion. 

M>  -a  languages  as  sum-  that,  when  a  program 
iii-  .  i  1  .  ,-rri'i  t  i  and  is  ready  t.-  run, 

!  !i  i  will  v  smooth!'..  i‘in-  expression  win's*.1 

.  piarv  root  is  to  :  »•  found  wi  i  i  not  turn  .ml  f 1 
!■»•  n»v.»?  i  l!  the  month  is  lehru.tr1.  ,  tin*  date 

si  ;  i  n -.a  he  given  as  il.  iwo  rati  i-  *  s  to  he 

-:n  1  i  p  !  •’  •••!  will  have  .  ompa  t  i  b  1*  .i  irneiis  i*’n  .  *Th*  n 

things;  a iv  *  ,is  they  should  ho,  t  .u-  fvpi.al 
r vspiiii.r  oi  the  .  nnputor  i  .s  t.  i;,sue  .»  warning. 

•:! es-.. i ge  and  then  abort  In*  pragrum. 

I -i  i  orif  r  cst  ,  Ada  is  do  -,  icin  d  to  permit  f  an  i  \  - 
?  ler ant  programming.  It  the  pi  .  v.rumr.-.et  *  .sn 
mtiripale  certain  *  lapses  .«!  abnormal  i:  ;  it  i"1;’., 
aii  i:  as  incerrei  t  Jut  i  being.  supplied  -  r  • 

■  ii  ill  at  *d  value  being,  out  -.id*-  the  ap;  ropi  i  .f  • 
range,  t  n  nv-.tc1-:  t  in  be  pi  ogr  armed  a-  knowi- 

tv  ihu-rmal  situation  and  de  i  :  vi  !  ii  it  in 

,v-P  iti’v:  we.  the  pr  ,  t  ammi*  r  has  a,  ?  er  **  in«  u  , 


allowing  the  ]u  ograr:,  to  «  uni  in<;«  Tanning  t  at  r 
than  t«>  terminate  u:nrr  a>  t*t  u  I  !  v  .  'n  a  fe.*.  iir-t* 

situ.sti\'n,  -or  exar.-.ple,  ex  option  .gi-iling  per:  it 
the  controlling  program  t ..  .out  in.-  running  •  n 
alter  re.«  iving  er  rone- i.t.i  ’  v  •  iu-t  r.r:,.  :.t 

[his  "i.iv  k«-ep  cti  .lirpl.it.*  ‘.vim’  'other  than  ;i::- 
gr  a*  «■;  u  !  ’  ’•  terminating,  i-ut  ti.it  is  ti.  a  u-  •• 

.  t  l  Isis  po  int  .  ) 

The  port  i  ru  1  ,r  '.•»!•»«•  m  tie-  i  !  e'-.m  :  •  in 

notit  v  ing  the  student,  in  a  tielptui  we.1,  1  <.t  e*. 

error  has  hern  det.ee  Led  during  execution.  i\  a  t :  i  «  : 
than  reacting  in  the  u>ua]  .in*  ■  *t  g  i  v  in*1,  ".aiuvr  u 
program  rrish,  t  lie  program  will  out  i:vac  t  ru-g, 
per  ii.ips  to  I  lag  .  met  her  error,  but  ■  vs  ;  b  !  v 
complete  the  ex<vuti  *n. 

Why  Ada  Fir_st  -’ 

Once  the  instructor  believes  it  is  possible 
to  te.n  h  Ada  to  the  computer- innocent  stusient,  he 
or  she  might  ask,  "Why?"  I’ndoubt  ed  l  y  the  student 
would  have  an  easier  time  learning  FORTRAN  or 
Pascal,  so  why  not  teach  either  of  those  before 
moving  on  to  the  more  complex  and  ambitious  Ada? 

Ada  was  designed  after  the  "software  crisis" 
focused  the  attention  of  the  software  community 
on  tile  problems  of  the  1970s.  The  discipline  of 
software  engineering  analyzes  these  problems  and 
provides  a  methodology  which  offers  great  promise 
in  their  solutions.  Ada  supports  the  b.isi. 
ware  engineering  principles  in  ways  that  earl:*: 
languages  cannot.  It  is  essential,  or  > t  least 
desirable,  that  these  principles  uj  go.>d  pr.  g.r.c- 
design,  as  encouraged  by  Ada,  be  instilled  is 
potential  programmers  before  tiiev  a  <piivi  tin 
customs  that  are  more  consistent  with  FORTRAN. 

The  reason  tor  lea.  liing  Ada  bef  ore  I’a '•*■.)’.  i  - 
d  ill  or  mi  t  .  In  a  beginning  Adi  .  ourse,  cm  norma  I 
teaches  eSSeiiti.il  iv  those  !  luair.  s  o;  the  l-mgaag 
that  closolv  resemble  Ibis-al,  ''•>  whv  v.'-t  V',-.1 

start  with  the  oisior  language.1  Ada  is  ,  ri.h 
and  powerful  language,  mu*  h  i:j.  <re  p*  >w.-r :  ii  ’ban 
either  Fascol  or  FORTRAN.  I*,  the  A  u’,’.  \- 

mately  to  a.hievi-  the  :ul!  power  of  Ada,  wh\ 
her.  in  bv  teaching,  svntax  and  st  rue  lures  tiiat  must 
eventual  ly  bo  super seded  ?  CU-uvlv,  it  is  'M  ev- 
able  to  teach  the  "Pascal  subset"  .*:  Ada,  wh  i  .  :i 
an  later  be  expanded,  rather  t  :ia:i  t  c.i.  ii  Pas*  *i, 
w!ii*  ii  must  then  he  mod  it  ied  in  i*  ..ruing  Ada. 


’[ciduiy  Ad. a 

.shell  the  ilistrili  t*.*r  has  lie-  iced  to  IiM.-:i  .sda 
fue  t  irst  prog  r  amir,  i  ng.  l.moi.i.v,  the  next 
i.lct  at  i  .m  i  s  "lioW? 

A  prog  i.ir-.  i:>  a  s«‘<|u*.  iv  e  *0,  ic.-uvr  t  icr.s  that 

■  1  :  I*  :  t -•  file  •  omptit  er*  in  th*-  per  f  <  im.in*  e  .  *  some 

■  onpuial  ion,  and  these  instriu  r  ions  must  ;,e  ex- 

:  ress.d  in  .1  1  or;1:  that  .an  be  under  si  >'od  bv  tin- 
m.i*  !i  ine.  Inti  I  the  program  is  a.  tuaTiv  subriTf  t  * 
i.  th«-  >Tij»utet.  in\  wiiling  1  ;  "ch  a:: 

a  .idem  i .  ex.-i.  is.  .  There  t  otv- ,  l  ‘u  a-c,d*:.l  h  -a. 
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he  writ  in-:  .i:x!  i'Xo  ut  liv,:  ;>rm;r.i“is  as  soon  as 
no  s  s  i ! '  if.  In  order  to  no  this,  tin  student  Warns 
qu  i  .  k!v  how  to  do,  Sure  basW  data  tvpes  and  t  * »  usi 
thvsi'  with  norms  t  svnt.tx,  proper  structure,  and 
good  !  o:  i  c  in  simple  prone. hires.  I  at  ortun.it  e  1  v, 
even  a  simple  program  requites  more  than  just 
writ  inn  the  Ada  .  ode.  I  he  student  must  also 
interant  with  the  hardware  and  the  operating 
system.  He  must  learn  iiow  to  log  on,  how  to  issue 
.  ommjnds  to  the  operating  system,  how  to  react  to 
un.e.xpo,  ted  responses  !  ron  the  operating  system, 
how  to  use  the  editor,  and  how  to  create  and 
:■  uni  pillule  !  iW  s.  He  will  have  to  learn  how  to 
des,  ribe  i  lie  interlaces  between  his  tiles  and  his 
urjutu",  how  te  nri'Ute  and  use  a  program  library, 
and  how  to  issue  < onmunds  lor  eompi ’ at  ion  and 
exe .  at  ion.  These  skills  are  probablv  second 
iMhir.  :  ■  the  i:ist  nu  tor  who  may  consequently  lost.* 
sich!  u  the  sheet  quant.  i  t  v  ot’  int'ormation  wiiieli 
tn<  -'t.-hiit  must  absorb  on  the  numerous  fronts. 


A 1  I  1  tiii  '  an  be  rather  overwhelming  to 
t  n*.  'u.i.ut  win*  just  wants  to  he  able  t  •*  lest  his 

p r  ■  ■ . r  !  ■  pi 1 1 « ■  t  i:e  square  root  , > »  ?•>-«.  lie  may 

t.iinr-  -  :,i*>  !'■*.■  e :  j  st  rinded  in  Haris  without 

■  an  :  'ne  !'ren<  1;  language.  In  other  parts  of 

!■  rm  •  .  .nv  it  tempt  t.*  speak  1- reach,  however 
n-i  iv,  i  1  ike!  v  :o  !>«•  greet  ed  with  :'r  Lend  1  i ness 
md  c  i/.er ,-s  t  .*  ommua  i cat »  ,  on  whatever  level 
i  i  ;*'’-•••  i  h  A  .  In  Paris,  however,  as  witli  the 
t  r ,  it  rite  svnt  ix  nr  vocabulary  is  not 
n't  •  ,  t*  t  .—.pt,  s  to  ..'311111  i  cat  e  will  probably 
h-.  •’  with  i  blank  stale  nr  perhaps  with  a 

r-  p  n  •>  tnat  is,  to  the  student  at  least,  un- 
1  1  i  1 »  .  This  is  most  discouraging. 


5  ami  liar  with  the  equipment,  a i  gu:*  .-a!  -iVht 
consist  u!  t  !i<*  st. .lent  supplying  m  i  as  i  ag  se-  r  ions 
1 ;  otherwise  complete  .  ode.  '[lie  regions  ",  is.  •in/ 

•  >*de  could  tin'll  he  expaiuled  as  :  he  .  >u»so  nr  *  ■- 
ressi-s,  w'u  i  le  the  amount  oi  code  pr"vid,-d  i  ■-* 

•.h‘v  rc.isoi,  until  eventually  the  student  is 
writing  tile  complete  program.  In  this  wav,  tin 
student  will  advance,  learn  h*v  to  interact  with 
t  he  i.  <  iinpu  ter,  and  1  ea  r  n  Ad  a  ,  at  ea .  n  st.ige 
receiving,  positive  feedback  t  n  r:  the  ■  ■  .mpu?  . 

Providing  numerous  examples  u*  *  o-q.  •  ,-t  * 
grams  will  help  in  other  wavs,  as  well.  •  •  .a  ten, 
in  illustrating  various  features  <u  r  h  •  !  anvuac.e  , 
■■•Hill  segments  are  given  as  exampWs.  The 
instructor  should  understand  that  it  is  a  n  u- 
irivial  exercise  for  the  inexperienced  programme: 
to  assemble  these  segments:  the  lumpletc  example-, 
will  provide  the  of  fen  missing  ini ormat  ion  ot 
the  wav  the  pieces  of  the  puzzle  are  put  together 
in  a  functioning  whole.  The  instructor  ni.iv 
illustrate  particular  loalures  by  focusing  *n  fin 
relevant  sections;  the  details  mav  be  -  . ! f 1 v 
ignored,  vet  will  be  there  when  needed.  Complete, 
working  examples  will  also  provide  the  studilet  will; 
the  opportunity  to  learn,  bv  experimentation,  the 
effects  of  localized  n«»d  i f  i cat  i ens  >n  a  success*  ul 
program.  The  examples  will  serve,  also,  as  model** 
in  tin*  development  ot  good  Ada  programming  xtvle. 

Tliere  is  an  ancient  Chinese  proverb: 

1  hear  and  I  forget . 

I  See  and  I  remember. 

I  <1  •  *  and  I  understand. 


In.  i « .  pr*i' Is  that  the  student  must 
.  i  •  tn«  rr.  o'  is  quant  :  t  v  of  information 

in  1  >  :•  n.  can  net  anv  *;s--!ul  I  eedba  k  from  the 
v  with  r  eg  ird  t  ■  •  his  Ada  code.  It 

•  w>  '  it  tin-  rictur  needs  to  minimize  the 

i"  lint  *  in*.,  rt.  it  i  n.  t  he  student  must  master  in 

■r.-ter  t  ■ :  .*  *  ’  t  a  mean ingf u  1  response.  One  way  to 

:  i-'  tiiis  is  *o  provide  tin-  student  with 

■  .,*  -omnle'i,  tested  Ada  programs, 

•  o  p-t  i.t-r  with  t  h«-  .  ;.-bv--st  ep  instructions  for 

•  i  t  in,:  wit::  tie  hardw are  and  operating, 
c.  .t*-.  I  hes .  •  >  ■  amp  1  > .  s  * .  1 1  *  'U  Id  make  it  i  lear  just 
W:...r  :•  irf  P  ;•>*•  Adi  language,  what  is  part 

o:  tnc  int-'rni  «  with  1. 1*..  *p* -rating  s  vs  tern,  and 

what  ;  'id  id.  i  l  r->  tic-  lud.nt.  Initially, 
tie  »t  ;d*  nt  *.i  -'n*  t  ed  demonstrate  onlv 

his  ibiiitv  :  o  1  ■  >w  ir.striii  ti-'iis  and  to  t  vpe 
orr..tiv;  a  dm  1 1  t  ;  1  v  ,  •  ii.-  senes  «**  i.  •  mnpl  ish- 
:-ent  wi  !  i  not  \n  a-.  rc.it  as  it  he  were  working 
;  nbepend.-nt  1  v,  but  a*  i.ast  t  a  i  lure  will  :  /*  : 
he  i  ■  i.ii-d  .  t Remember  :  ass  ignment  is  sc 

simple  tn.it  v  l’  .ot  co  wr-Mic,.)  At  first  ,  ot 

■  •cir-*e.  tiic  -.tud.-nt  vi!i  :n-L  under  st  and  the 


pa.  him  jay  lU  is  new  enumeration  iU(l)av); 

I 

1  i  in-i  >-r  st  an*5  them,  se  tie 
III  the  pt'.  ■  ess  the  ‘it  -l-bllt 

or  mat  i  on  «l>  >u*  i  pm  p.-r  , 

When  t  lie  •.!  ,d>  ut  i  • .  -  |‘e 


The  examples  provide  not  only  the  "see,"  ‘put  im 
of  ononamis  help  in  the  "do"  that  is  ahsolut.lv 
crucial  in  learning  any  programming  language. 


Topics  in  in  ljU  rocluc  t or y  Course 

A  reasonable  svl  lahtis  for  the  first  >  curse  in 
Ada  won  !<1  im  liuii  program  structure,  discrete  and 
structured  data  types,  statements,  de  .  larali.um 
and  hh'i  ks,  suhprog. rams ,  and  packages.  Instant  ia- 
t  i»'n  o!  the  generii-  Text  It)  is  unavoidable  and, 

.  omen  i  ent  1  y  ,  not  dilficult.  1'ser-det  ined  geiuric. 
mk-  mure  ambitious  and  may  easilv  he  postponed.  A 
number  of  the  features  that  make  Ada  such  a  r  ‘  h 
and  powerltil  language  nav  also  be  quite  dif:  :  ult 
lor  tlu-  beginning  student..  For  t  unit  e  1  v ,  soph-  «*! 
these  (access  types,  tasking,  low- level  It),  and 
user-de!  ined  generics,  tor  ex  triple)  i  in  sat  els*  he 
igtn’red  in  .ui  Introductory  course. 


I'm  or  ?  nn.it  e  l  v  ,  I  have  :i"t  vet  s«-eii  an  Adi 
text  wlii.ii  i  -  su  i  i  able,  in  itself,  tor  a  heginnin,- 
.  ourse.  I.ithcr  the  text  is  at  an  elemenimv 
and  does  an  inadequate  i<'!>  ot  covering  the 
language,  or  it  assumes  expet*  i  eiii  e  with  some  (her 
high  order  language  and  tends  to  eovor  the  basics 
•  a  Ada  r  it  her  qui..  klv.  Mv  prelerence  would  be  to 
.boos*  "iir  >>t  ttu-  latter  type,  supplement  it  with 
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S  i  >n  [  ' ■  !m‘i  I  i  t»i  .  i  { ill  "I,  >Ve  .112  1  V  S  1  *  *Vv  !  '• 

nt  t !  1 1  ■  s  e  U'>;t  s  ::iv  Mvoritf  in  Youni: 

...  iu-.iu  t  i ;  ,  1  1  v  clear  and  complete  esplana- 
ii  ih  an  updated  edition  of  Barnes-  (soon 
liiahlr,  l  am  l  •■Wl)  :n  i  ,*  ht  run  a  close 
|i,iinh  and  tlehani'  arc  excel  lent  al>»o. 
’.nr  advanced  iCarM'S  or  for  supn  lemon  t  a  1 
in  till-'  •  oar-ie. 


C»>m-  lui"  '•  an 

huu.’.uaro  helps  shape-  thought  prinn-ssi-s.  •  tii :» 
fra  •’.*  nr- -nranm  i  m:  inn^ua»;es*  as  well  as 

i  'u  i.n  s  •  The  Ada  prouranmtni;  lanytuap.e  was 
•icned  with  the  principles  of  readability, 
in  standabi  I  itv,  and  modularitv  of  paramount 
,,-f  t!u  ,  Ada  support  s  the  development  of  yood 
rar.tr:  i  pra-  tires,  logical  structuring,  and  an 
,t  n.  s  that  tin  programmer  lias  a  responsibility 
c.cike  sis  program  understandable  to  future 

uit?,  •  ;U.  jnereasim;  eonipl  ex  i  t  v  oi  Iar>*e 
, ; svstens,  the  instruct. >r  should 
,M;r  i  :i  ♦  a,  modular  approacli  to  a  problem 
th.-r  *  !  i ;  i :  i  tin-  sequential  approach  used  with  most 
r  !  it  i  croc  ramming  lancuapes.  The  student  learns 
•louvfal  ‘crop,  ram  design  met  hodo  I  o>;v  with  Ada, 
v,  :  *  .  the  la:n;ua«;o  itself  . 

A.),  { ...  t  l.irm  and  ■•omplex  lain'.uape,  and  it 
|..l;,v  to  Irarn  or  to  t  ra<  h.  But  the 
•  ,  :i r  .  ptuir!  its  are  tremendous. 


i ;  ,rd.  \d  t .  An  1  nt  r  <  >dri.  t  i  ■  mi ,  Springer- 

V.  i  !  .  1  h 8 

I#  i  ,  Ada  amtn  i  up  l-  iupua^.  . 

:*n  id  i  <  .-Hal  l',  " 

f.  A.  Saxon  and  R .  K.  Fritz,  Be^ inning 
ur ramming  witii  Ada.  Prm  t  i  re-Ha  l  1  ,  1981. 

U.  W.  w  i *  n ** r  and  R .  Sim-ove.  ,  I’/'^r.iprii!^  in 
A  ( ,  Mini  U'ilrV,  1988. 

I.  V  i  un  v. ,  An  I  nt  rodu*  t  ion  (■  i  Ada, 


54 


AD-P003  423 


’VI-UTKi*  ,'Y.GbM 


*.  ;  hrvut  M.  H.irdi; 


;  -  :  :  i  -i  t  •  :  ■  o  p  i  !. 

:•*'!*  «•  •  •  '  K-:.  \  |  r  •  *•:.,  .a..:  •  . 

,  r  :  i  .  ‘  i •  ip,.».n 1  I  i  t  i  »•:•, .  :  .  one 

:  !  :  •  *  .  :  •  .  . i  ret h  t  o  t  ■  1 1 : :  t.  r  l  — 

:  .  *  ;  .  :  :  '  *  > :  •.  ;  r  i  :  -  •  .j  1  i\i  »  wo  r  <  o  i  c-.»n- 

’  ;  -  i*  :  i  .  r  n  are  i  i  so us sod  ,  i n 

t  :  .  ’  .  ■  •  •  •  r, :  4  jur  at  i  jh  ana 

:  •  w  <i  I  I.  n.  •  .  ;..n«.:nt.  1  n  ;  1  it  i  The 

!"  :*  .  >i  a  i  .*  r  .  t  ..it  »•  i  A-.i.i  pr  u  j  r  anis  is  then 

‘  •  •  r  A  t  *  e  [  the  pint  o  t  y  pt  soft* u  i  r.- 

.  .  *  fit.-  project  will  focus  an 

i  .  j  t  h  e  pe  r  t  ■ :  m  a  nc  e  o  hat  after  inti  c  s 

!  n*  *  «<•-  *  k  :  .  •  pa  l  £  i  ca  1  1  y  ,  on  disit  i- 

.  if  i  ••xe  ‘nr  i  ve  not  t ware,  and  Ada 

1  r:  } i j  f  <e  .  V r  I  : leads  . 


If;  t  r  oduc  l  i_o  r  * 

F  r  ;*» .  i :  i  >  , u  r  s  the  hardware  a  rehit  oc- 
t  •  i r  v  *  y  pii-.il  *>t  :i;  i  1  i  •.  ary  real-time  systems 
:.i.  been  distributed.  That  is,  many 
pu'  *  r  .  .u?  connected  together  by  communi- 
■■Mt  til!.,  .ntih.':;.  However,  the  software 

for  these  systems  does  not  pro- 
.  .  ■ !  e  t  r  incremental  growth,  one  v,i  the 
i  :  v  a  n  t  i  j  v  s  po  s  s  i  b  1  e  w  i 1  h  d  i  s  t  r  i  b  u  t  e  ■-  j 
i  r  oh  i "  e  :t -j  r  es  .  In  general,  the  software 
exhibits,  a  high  decree  of  coupling  to  the 
hardware,  *  he  operating  system,  and  the 
coninun  i  o  i .  i  )n  methods,  due  to  the  fact 
t  ha ’  f  he  functions  f>  be  performed  are 
wr:Mo;  for  s  pe  c  i  1  i  c  conpu  ter  s  in  a 
machine  dependent  manner.  Thus,  the 
saftwar**  nun  to  be  redes  igned  each  time 
.1  no  r  h*‘  r  .''input ..  er  is  added. 


Another  characteristic  of  real-time 
iti.itoiy  computer  based  systems  is  the 
importance  ol  high  reliability.  Many 
t  l tli is  is  achieved  by  having  a  dupli- 
:at«*  system,  known  as  a  hot  standby  or  hot 
stiinq,  so  that  should  the  primary  system 
fai.,  processing  would  then  be  transferred 
to  the  hot  string.  Techniques  are 
currently  being  developed  to  ’  otect 
failures  of  hardware  devices  and  software 
modules  in  distributed  systems.  Process- 
i;  j  could  then  continue  using  the  r ema in- 
in  j  resources  of  the  system.  This 
represents  a  potentially  less  expensive 
alternative  to  the  hot  string  approach  for 
achieving  reliability. 

Although  tn*.  hardware  in  the  above 
systems  is  distributed,  the  so 1 1 wa i e  i s 
not,  making  the  potential  advantages 
(incremental  growth,  enhanced  reliability: 
of  distributed  systems  impossible  to  real¬ 
ize.  A  methodology  for  J  i  s  t  r  i  but.  i  n  j 
sol  t  ware  is  needed  which  will  minimize  it.- 
complexity  and  singularity,  and  at  the 
nan*.  time  provide  capabilities  for  fault- 
tolerance  and  incremental  growth  with  a 
in  i  n  i m um  am o u n  t  of  redesign  e  £  f  o  r  t. . 

A  a  a ,  the  new  programming  1  a n j u a  g  e 
designed  for  the  DoD,  contains  features 
which  could  support  the  construction  of 
distributed  software  [5J.  However,  there 
isn't,  any  agreom*  nt  as  to  flow  t  fa.-  vu  i  .-us 
language  constructs  should  be  used,  r 
even  how  constructs  such  as  tasting  s.v.;  .il  d 
be  implemented  for  the  distributed 
environment.  The  implementation  chosen 
will  impact  the  way  the  feat  art-':  con  be 
used  to  write  programs.  So  f  t w  a  i  e  s u p t  t 
tor  dc'Ci-  :  t  r  a  1  i  zed  programs  in  the  form  o  ! 
p  roefo  '  n  d  mentor  y  man  a  q  e «..•  n  t  will  b 
needed  once  the  other  issues  have  beeri 
resolved.  Finally,  some  metfiod  t  *r 
assigning  software  units  to  pi  jce.no  i  :•  is 
needed. 


*  Ada  is  a  registered  trademark  of  the  >J .  .  Government  (Ada 

J o  i  r , i.  P r  og  r  am  Of  f  l  c «« ) 

' ■  -  y  r  i  )  h  t  A :)  1  (J 8 4  h y  Hi ig  ti e s  A  i  r  c  r  a  1 1  > n <i  n y 
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This  pi  pe  i  i  L'f  o  i  l  s  c?  n  j  pi  o  j  e  o  *_  t.  ■ » 
c  o  n  s  t 1  ;K‘  *  s  prototype  distributed  -i:. 

i  rip  i.  ef;ie  n  t  ed  in  Ada.  Ar,  ear  iiet  vorni  on  .)! 
tht-  paper  *ji;  pub’i  shed  1 n  [It;]  .  The 
i  n  t.  : 1 1.  - .. :  the  p  t  :  >  ’  c  t  1  a  t  o  :  t  I  )  d  e  v  »_*  l  >  p  a 
sot  t  w  ■.  r  »_■  a  i  ch  i  t  ec  t  ur c-  r  ha  t  up p-.,«  r  i.  s  t  r  an- 
spar-.m  distribution  ot  appi  i  .‘at  i <»n 
sot t ware  in  a  i  )Oni  network  at  cummin i oa t- 
i  n  g  p  r  o  l*  t-  s  s  a  r  s  ,  2  )  t  u  k  e  a  d  v  a  t  i  t.  a  j  e  o  f  L  h  e 

pate  ri  till  to  e  n  ot  its  o  t  t  e  t  e  d  toy  distribute  d 
a  r  oh  a  t  ec  t  ui  us  ,  >;  \ )  assess  the  use  of  Ada 

a  s  a  p  r  o  g  r  arm  i n  j  1  a  ng  u  a  g  e  tor  real-time 
embedded  systems,  (4)  detine  fault  detec¬ 
tion  and  recovery  techniques  which  allow 
t  t\e  sys  t on  to  deg  r  ad t  gracefully,  and  ,  ( 5 ) 

evaluate  the  overheads  of  the  Ada  network 
(having  the  capabilities  just  described). 
Section  2  of  the  paper  describes  trie 
hardware  configuration  and  the  facilities 
use d  to  develop  software.  The  third  sec¬ 
tion  discusses  some  of  the  motivations  and 
methods  tor  distributing  software  in  a 
.local  network  of  loosely  coupled  process¬ 
ing  elements.  Section  4  describes  the 
mode  1  chosen  t  o  d i at  r i bu te  Ada  pr  og  r  an 3 
.1  cross  the  network,  and  finally,  the  last 
a-,  ct  ion  summarizes  the  contents  of  the 
puf  er  . 


2 .  Ada  Network  Hardware  Configuration 

The  .hardware  is  configured  as  a  local 
area  network  iseo  Figure  1)  consisting  of 
two  Intel  432/670  systems,  and  an  Ethernet 
contention  bus  as  the  communication 
m  e  d  i  on  .  Fla  oh  4  32/  ♦'  7  u  sys  ten  will  be 
r  o  f  e  r  r  ed  t  o  a  s  a  4  1 2  pr  oce ss  i  ng  e  1  erne  ri  t 
due  to  the  fact  that  a  432/670  system  con¬ 
tains  multiple  processors.  One  of  the  432 
p r  o c e s s  i  n g  e  1  e rn e r.  t  s  i  s  c onnect e d  t o  a 
microprocessor  ieve lopment  station  (MDS) . 
done  sol t  w  - 1 1 -  ivVelopnont  is  done  on  the 
MDS;  in  addition  it  is  used  to  load  and 
■debug  the  4  32  systems .  The  MDS  is  con¬ 
nected  to  a  VAX  1 1/780  where  the  Ada  com¬ 
piler  i  s  h  o  s  t  e  d  [  8  j  . 


The  architecture  of  the  iAPX/432  is 
.‘.one what  different  from  conventional  com¬ 
puter  architectures  [7,0],  An  iAPX/432 
'  /'tur;  contains  general  data  processors 
i  ..CPs;  ,  interface  processors  {IPs},  and 
it  tic he d  processors  (APs).  The  attached 
pr  ■c#?;;sor s  (there  can  be  many)  manage  any 
p*  r  ipnt-ril  -vices  in  the  system;  one  AP 
jr..:  .  fs  associated  peripherals  is  some¬ 
time.,  referred  to  as  a  peripheral  subsys- 
Tn«-  GDPs  (again  there  can  be  many) 
ir-  tie-  •c't.ual  4  3  2  processors;  they  exe- 
•  . ?  •  A;i  programs.  The  interface  proct*s- 
■r  -r  !•:  ,  ir-  use  i  to-  transfer  data 
:  •  f  t  se  .dd  s  if.  1  tin?  APs.  In  our  con- 

:  ■.  .  i  c.  i  e , ,  •  i  iAPX/4  32  corn.  a  ins  two 

G  P  ,  .re  AP,  in  i  ora-  IP  (see  Figure  2)  . 
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Figure  2.  One  IAPX/432  Processing 
E 1 ement 


The  AP  is  an  86/12A  which  uses  the 
1RMX88  operating  system.  The  AP  in  both 
iAPX/432  systems  will  be  used  as  a 
common  i  ca  1 1  ons  pr  ocesso  r  ;  it.  will  fia  ve 
software  to  send  and  receive  messages  over 
t  h  e  E  t  i  i  e  rnet.  So  f  t  wa  r  e  for  1 1  ,e  $  0 ,  t  2  A  is 
3  e  v  e  lop  e  d  l  n  P  L  /  M  or  3086  a  s  s  o  m  b  1  e 1  . 

The r  e  a  re  t  wo  IPs,  on e  for  ini e r  f a c i n g  t  o 
t he  86/12A,  and  the  other  tor  conmuu i ca t - 
inj  with  the  MDS  (it  resides  in  the  MDS i . 
Software  to  control  the  IP  exists  on  both 
the  GDPs  and  the  AP.  Final  1 y ,  there  are 
t  w  o  GDPs.  It  is  pu  s  s  i  b  1  e  t  o  e  x  p  a  n  i  j  t.  h  o  s  e 
s  y  s terns  with  either  n  i  o r  e  G  DPs  a  r  A P  s . 

The  M D S  e X e c  u  t  e s  t  !\ e-  I  />  I  S-  I  I  at; e  t  :■■*  - 
inj  systion  which  contains  software 
d e v e  1  o pm e n t.  t  o o  i  s  t  o  r  the  8  6 ,  I  2 A  :  a  P I.  / M 
comp i I e  r ,  a  1  i  oke  r ,  and  a  1 oade  r .  The 
1  .'either  in  an  iSBC  9G7B  monitor;  it  is  also 
used  to  debug  the  software  .>n  the  86  2  1 2  A . 
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l 2 )  the  iAPX/4  32  has  software  transparent 
m  ult  iproces  s  i  n<j  capabilities.  Tran  s  pa  r  e  n  t 
multiprocessing  refers  to  the  fact  that  it 
is  possible  to  add  more  GDPs  to  the  4 J2 
system  by  just  plugging  the  boards  into 
the  backplane.  The  software  will  automat¬ 
ically  incorporate  the  new  processor  and 
assign  processing  to  it.  Some  other 
features  uf  the  432  are:  (1)  hardware 
operating  system  prim’  ives,  and  (2)  fault 
tolerant  capabilities  .  ..one  operating 
system  primitives  have  been  incorporated 
into  the  hardware  in  an  attempt  to:  ( 1 ) 
improve  their  performance,  (2)  accelerate 
the  software  development  process,  and  ii) 
standardize  such  operating  system  primi¬ 
tives.  Fault  tolerant  capabilities  exist 
in  a  couple  of  forms.  In  the  : inpiest 
form,  should  one  of  the  processor...  fail 
(within  a  processing  element),  the 
software  will  detect  the  condition  and  use 
only  the  remaining  GDPs.  It  is  also  pos¬ 
sible  to  have  more  sophisticated  cap  ibi 1 i- 
ties  by  using  Intel  chips  which  provi.h 
tor  quadruple  modular  redundancy  jMPi  uni 
shadowing.  shadowing  is  when  two  proces¬ 
sors  execute  the  sane  code  and  detect  any 
d  i  sc  r  epc-nc  i  es  between  them.  ,,MK  is  when 
there  exist  two  pairs  of  shadowing  proces¬ 
sors,  one  pair  designated  a  master  and  the 
other  a  slave.  It  the  master  detects  a 
discrepancy,  then  the  master  disables 
itself  and  the  slave  becomes  the  new  raas- 
t.  r  .  Thus ,  tlie  4  32  system  has  some  new 
f-'itures  that  are  not  offered  by  more  con- 
v n*  ional  -onputers. 


(.  Mot l vat  ions  for  Ada  Network  Software 

As  mentioned  before,  distributed  com¬ 
puter  systems  nave  the  potential  for 
increased  reii  ability  over  single  proces- 
.,:r  systems,  ml  fir  incremental  system 
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a  distributed  system.  As  shown  above,  the 
hardware  resources  are  decentralized. 

Thus  it  remains  to  devise  a  method  for 
constructing  decentralized  software. 

One  method  advocated  by  researchers 
for  decentralizing  the  control  and  data 
structures  of  software  is  to  construct 
programs  as  collections  of  autonomous  com¬ 
municating  processes  i  1,2,3,4,61.  The 
processes  are  designed  to  be  autonomous 
entities  since  they  may  be  on  separate 
processors.  Interactions  between 
processes  are  well  defined  and  independent 
of  the  actual  distribution.  Between 
interactions,  processes  on  separate  pro¬ 
cessors  are  capable  of  running  in  paral¬ 
lel.  Thus,  the  process  requires  no  cen¬ 
tralized  control  and  is  the  software  unit 
of  distribution  and  parallelism. 

Coordination  between  autonomous 
processes  to  perform  some  function 
requires  the  ability  to  exchange  informa¬ 
tion.  Because  the  run  time  configuration 
is  variable  (e.g.  in  the  case  of 
failures),  the  actual  configuration  should 
be  transparent  to  interprocess  communica¬ 
tion.  This  goal  can  be  achieved  by  pass¬ 
ing  messages  between  processes. 

Because  processes  are  autonomous  and 
navi  no  centralized  control,  some  means 
must  be  provided  for  process  synchroniza¬ 
tion.  For  example,  a  process  which  serves 
a.,  a  device  handler  must  have  control  over 
when  it  accepts  requests,  perhaps  how  many 
it.  uo  '•  [its,  arid  i  r  >n  whom.  Also,  a  ur  >- 
cess  using  the  service  might  .need  to  wilt 
I  -<r  its  completion  t>.  lore  con  t.  i  nu  i  n  : . 

Tin.-  absolute  timing  of  a  pit  t  i-'ular 
process  cannot  be  predicted  due  t the 
tact  that  processes  exist  on  sopor  »te  [  i  .- 
Cessing  elements,  each  with  their  >wr; 
env  i  roiwent  .  S  i  nee  the  t  imj  r. )  oi  a  s  ;  n  i  I 
process  cannot  he  predict!.  ;,  nei'her 
'he  timing  of  interactions  twee, 
processes.  For  example,  a  process  whi 
is  to  be  used  by  several  other  prose- 
cannot  always  guarantee  be  t  >  r  eh.r.’i  i  t 
ordering  of  requests.  This  irnf.  i  I  .  •  .  • 

predict  or  guarantee  a  sequel,  ■,  ;  .••••:! 

means  that  decentralized  and  li  t  ;l..’  r 
software  is  inherently  nondet  ermi :.  i  .•  ■  • , 
and  a  distributed  system  language  -  u  ••  •  . 

designed  to  tolerate  some  de  it  •.  .  ‘  s- 

Jeterminism  in  the  intpricr  i  s.  o 
processes . 

Ada  contains  !  . .  •  t  . 

which  support  ill  ■  . t  tile  ;  . ■ ■  , r  •  , •  ....  : 

above.  The  }  .  ’e  .  :  ;  :  :  an:  t  i-ki-i; 

■  (  r  iic  t  s  sin  lie  ii..;*  . i  r  .  -  r  .  : . 

[■  r  .‘SSL'S  wh  :  h  can  In  :  ;  .  t  t  .  :  .  •  •  :  . 

All  r  l*1l.  :*■  z  v.  ■iis  ■  a  ;■  sha.si  in  w's  -1,  ii  w 
'  •  ■  ‘  ’  •’  x  I .  i :  i  l  n  i  - .  r  ■■  a :  i  s  .  In  ■  :  :  ,  - 
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t.  1 


j  the 


-1  .  A  d  a  I  n  •  p  1  -  p.  i  e  n  t  a  t  i_  c  >  n 

Tiit/  s  o  L  t.  wa  i  <:  tor  the  Ada  net  wot*  is 
■  vrisL  i  uc  ted  f  o 1 1 ow i g  a  typical  1  aye  t  tM 
i p  r  vj  a  c  h  .  The  top  1  a  y  er  i  s  t.  h  e  a  p  pi  i  _*  a  - 
...  i  •  n  p r  og  r  .in  (  s )  ,  written  i  n  Au  a  .  'J:uie  r  - 
: i •.  it:: i  the  application  Ada  code  is  some 
support  software  to  execute  Ada  pi  og  r  oins . 
The  support  software  takes  the  form  of  .m 
operatin'.;  system  kernel  which  supplies  a 
i  ■  i  n  i  n.  i  *  ;er.  of  primitives.  The  opera  t  i  ng 
oyster,  that.  Intel  supplies  with  the  4  32  is 
iVAX,  which  contains  process  and  memory 
"••.in  a  jemerit  functions  tor  programs  execut¬ 
ion  eri  .i  single  processing  element.  The 
i VAX  functions  will  be  extended  to  support 
.i  .  c.  t  t  i :  ■  u  t  e Ada  programs.  Finally,  the 
to:  i"i  1  ty.-r  i ...  communication  network 
1  r  j  r  which  supports  the  transmission 
•  • r  *  s  ;•  .  bet  ween  processing  elements. 

r.ie  it  ,ues  being  addressed  in  imple¬ 
ment  ; i  a  iirtt  version  <>i  trie  Ada  network 
wi*:.  •  ;*.  :  in  it  tolerant  processing!  are: 

'  ’  •  ?  r "i  "i  iistr  i  r  ated  Ada  program, 

1  t::g  iemero  ion  o!  the  kernel  to 

supper:  • he  distributed  Ada  program,  (31 
.-.’/stem  startup,  and  (4  I  the  assignment  of 
s  o  i  t  w r\  r  e  u r ,  i  t  s  t:  o  p  r  o  c  <•  using  e  1  e  me  n  t  .*■  - . 

T  n  e  r  o  s  t  o  t  t.  r ;  i n  s  e  c  t.  i  o  n  will  discuss  t  h  e 
first,  two  issues. 


One  plan  for  implementing  distributed 
Ada  pro-  rams  assumes  that,  a  single  Ada 
pro J ram  will  be  distributed.  The  implica¬ 
tions  are  the  following:  (1)  the  semantics 
t  the  Ada  rendezvous  and  Ada  programs  in 
;j »:  ne  r  a  1  w  i  1  1  oe  p r  o se  r  v ed  a nd  i  rnp  1  erne  n  ted 
in  a  distributed  fashion,  and  (2)  the  com¬ 
piler  will  be  used  to  perform  the  usual 
:  om p  i  i  r  c  n  e c  k  s  b e  f  o  r  e  t. r i e  p  r  o g  r  am  i  s  o  x  e - 
cut*1:!;  thus,  syntax  checking  of  a  distr  i  - 
bate  i  rendezvous  and,  in  jenerai,  a  d  i  s- 
t  r  i  b u  t.  t.’d  p r  ng  r  an  i  s  po s  s  i :..  i  . 


Assuming  t! 
distribute  pr o 

h e  a  1  1  awe  i  will 
jrar...;  th-it  Ada 

pr  it  ar:  by  in  ,:o 


at  t  a  s  k  s  will  : 
c-sini  anon.)  pr 
peS  : .■  t  programs, 
r.-e  "i  ib;-'*  of  t 


iSu.l  Lm 
ce  ;  i  r:  j 
a at  will 
•  pr  >- 


a  among  *  i.-. k.i  in  an  Ada 
po  r  at  i  n  j  v  j.  k  s  i  ns  ide  a 


i  i",  mi  navi-,  i  data  it  lu  at.  ions  t.  > 
i-  1  :  i  in  si  ie  the  package  have 

■  -  .  ".'hi  .  fyp‘-  t  it  ri!'!  will  :v»t. 

1  •  .>'*•-  :  :  ;r  t  w-:  reasons.  First,  it 

t>  »t  ‘  :.t  ■  t  :::  ‘  ■>  *  h-  made  1  •»}  aut.o- 
pf  »♦’  S  ,  S’  j  ’  aid,  It  is  nei- 

•  *  t  a  ;  j  h  t  j  :  i  w  i  r  :  u  ■  r  e  f  t  i  e  l  e  n  t  to 
-  *  i.-b  i  .  i  i?  i  :  •  ’  i  a  t  i.ng  i>e  t  we-er.  pr 

i'ii  *•  i  w:,.  •  J •• 1  not  c.ha r  e 


1  •  ••  1  '•  J  a  -see; 


i  nco  r  - 


u  i  n  j  *.•  1  -rent  .sent  if  i  - 
he  ad  U  r  v p  as.  i  *:  J  1  o  r 


Tri'.-  r  :  in  t.  ryinj  to  implement 

;  i . ;  m  •  i « •  I  :  it.  requires  mo  6  i  f  i  c  a  - 

*ions  t.  t  :if  ncspii-t,  linker,  loader  and 
runtime  system.  Tn*.  reason  is  that  during 
t.  se  i r., p  1  om -nt  a t.  i  •; n  a  t  U; e  ; om p  i  1  e  r  and 
es ;n c  i  ite-i  A.ia  support  software,  the 
assumption  made  was  that  a  program  would 
o  x e c u t  ..-  n  a  s  i  ng  1  e  proce s sot  o  r  a  :n ul  -• 
t  i  pr  oces.-o  r  with  shared  memory.  Although 
i f  is  assumed  that  some  changes  to  the 
t  j n t  i me  s ystem  will  L  e  n a d e ,  c on p i 1 e  r 
m  o d i f i c a  t i o n  s  are  outs* d e  t  h e  realm  o  f 
this  project. 

An  alternative  model  of  a  distributed 
system  is  one  where  the  entities  that  are 
distributed  are  tasks,  but  where  there  is 
(at  least.)  one  Ada  program  per  processing 
e  1  erne  n  t .  I  n  o  r  d  e  r  t  o  e  x  c  h,  a  ng  e  d  a  t  a  or 
messages  between  tasks  in  different  pro¬ 
grams  it  is  necessary  to  define  a  conven¬ 
tion.  This  convention  could  not  be 
checked  by  the  Ada  compiler  for  syntax  or 
other  errors.  The  advantage  to  assuming 
this  type  of  program  model  is  that  it 
would  be  easier  to  implement.  It.  would 
not  be  necessary  to  modify  any  Ada 
s  j f  t  w a  r  e  s u p po r t  t  jo  1  s .  A 1 s o ,  the  issues 
. i  e scr i b e d  a  bo v e  (global  d a t  a ,  a c c  e s  s 
types)  are  not  of  any  concern  in  this 
case.  The  convent,  i  >n  or  protocol  defined 
c  oulu  t ;  *  ■  i  :’i  p  1  e  m  *  •  n  t  •  ‘ ;  i  a  .;  "  a  ppl  i  a  t  i  o  n  "  A  d  a 
t.  a .-•> k : , .  The  • :  :  . •  ad v  a n t  u g o  o  f.  t  h  i  s  me  t ho d  i  s 
t  :  i  -  i  t.  s  •„>  m  i  ■  1  c .  1 1  i  a  n  t  r  a  n  s  p  a  r  e  ncy  is  lost. 

:t  i;;  possible  to  Ii  a  vo  parallel  activity 
mb  i r  enu.  n  t.  a  1  giowtli,  but  now  many  of 
tie.  f  a : ;  ks  a  r  e  a  ppi  i  :  a  t  i  o  n  s  pe  c  i  i  l  c  a  n  d 
t  hus  be v n n e  *  h e  r  • .  s p> ■  > n s  i  b  i  1  i  t. y  o  f  the 
: .  e : ;  i  j  i  e.  -  r  pt  og  r  a;:,  me  r  ,  who  now  r  i  change  has 


7  \ .  •  ■  i- 1  j  a  el  >  f  i  i  s  t  r  i  b  ute.3  p  t  o  g  r  a  m 
t  ?  r  t.  Sie  Ada  network  is  the  second 
•:  >  n e  •  >  i;  t  1  i  ri  e  .i  bo  v  e  .  A 1 1  h o  ug  h  t  h  e  f  l  r  s  t. 
model  i  t!ie  preferred  one,  t  h.e  level  of 
e  f  f  •.?  r  t  required  is  not  w  i  t  h  i  n  t.  h  e  i  i  m  i  *.  n 
of  *  r. e  r e s o u r  c e s  a v a  i  I  a b  1  e  > n  t  h  i  s  p r  o - 
e c  r. .  Th  u s  some  o  f  t.  he  i e  s  i  r  ed 
capabilities  of  the  Ada  network  will  not 
be  r  i?a  1  i  zed  with  t ti  i  s  mode  1  .  Howe  ve  r  , 
witii  this  clio  ice  ot  implementation,  it  is 
possible  to  prototype  an  experimental 
'  a  pub i 1 i t  y  i n  a  r e  a  so  n  a b 1 e  amount  of  t  i  me 
a n 1  then  assess  the  over  h e a  d  i n v o 1 v e  <  j  w i  l  n 
i  i s t  r i b u t i o n  a n d  the  us e  o f  A d a . 
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PROCESSING  ELEMENT 


Re  n> 


vu  US 


n  f :  t  o  1  ‘  . j  w  i : i  i  d  i  s  us ion  j  i  v e  s  *.  h  e 
■  i o  t . i  i  1  s  .>  l  m e  L  h o d  ,  c  .1  i  i  o d  a  p so ud o  r  *_•  n - 
J  o  z v  u  s  ,  I.  t  i  r. p  i  n e t  i  ng  a  1 1  i  s  t  r  i  b u  t e d 
i  e  n d  e  z  v  o  u  s  a s  s  j;:i  i n  j  that  t.  h  e  so  t  t  wa  r  e  unit 
o  t  distribution  is  the  task  in  i  ^dependent 
Ada  programs.  This,  method  does  not 
require  changes  to  the  compiler,  linker  or 
o  t  he  r  s up po  t  t.  so  1  t  wo  r  «.• .  At  t  he  sane  t  i  me  , 
the  intent  is  to  preserve  as  much  of  the 
Ada  rendezvous  semantics  as  possible.  The 
primary  support  needed  for  such  a  model  of 
distributed  programs  is  some  communication 
network  software.  Since  the  entities  on 
separut.H*  processing  elements  are  programs, 
the  pro  cress  and  memory  management  algo¬ 
rithms  that,  exist  in  iMAX  can  be  used. 

A  normal  r  •.  n  Je  ::  vo  us  ,  shown  in  Figure 
1  ,  f .)  t  o  e  s  t  w  t . . s  -s  s  t  o  s  y  nchronize  at 
their  respective  CALL  and  ACCEPT  state¬ 
ments.  The  cali--r,  task  A,  specifies  an 
entry  point  in  another  task,  B.  When  task 
h  r  caches  the  specified  entry  point  (an 
A1 '''KPT  statement.  ,  the  rendezvous  takes 
p  1 ..  i  c  put  p  a  r  i  r.  e  t  e  r  s  c  a  n  b  e  passed, 

an:  r.  sen  some  processing  can  take  place 
•  .  n  Ad  :i  "hi.-,  is  d  one  by  the  server  task)  . 
Wh*  *.  re.  ;  rocessinj  i finished,  output. 

;  ■«  r  i'"- ■■  *•  i  -■  are  passed  and  then  the  c.jlier 
hi;Si  r-s  am  as  execution. 

Figure  A  shows  t  ne  same  i  endezvous  in 
d  :  ;  t  r  :  bu  t  :  t  ;rm  .  caller  now  cal  is  a 

sur  t  jpi •>»  procedure.  The  purpose-  of  the 
s .  j  r  r  o  g  a  tc  pt  j  c  e  d  u :  e  is  r r  r » ,  sm  i  t  t  h  e  i  n 
a  r,  J  i  n  u  t  p  a  r  a  me  t.  o  r  s  ,  it  *  r  ■  y  ,  to  t  h  e  c  on- 
'■  c  i  it  ion  subnet  ilong  with  the  iestina- 


F  Lgure  3.  Nornal  ADA  Rendezvous 


t  ion  name  of  the  intended  task  ,  r. :  *  - 
wait  for  the  results  of  the  r  zv  j  is 

(status  and  out  parameters,  i*  iny  wr. 
will  then  be  returned  to  the  c  i  i  1  •  •  i  . 
destination  name  spec  it  led  by  *  ::**  n: 
gate  procedure  is  t h e  n a m e  o t  i  s  a  t  t  >  a 
caller  on  another  processing  e  i  ers  c.  t  . 

:•»  u  i  r  o  j  a  t  e  cal  1  e  r  i  s  a  t  a  s  k  w : ;  o  s  e  :  • ,» r ;  •* 
is  to  wait  for  "cal  1  t  r  j«  *  r>.  o-.r.mun 
t  ion  net;  when  one-  is  received,  *.  r.e  s  n 
g  3 1  e  caller  •  a  I  1  s  t  a  s  k  5 .  Aft  e  r  ■  -s  s  k 
c o m P 1  0 1  e s  its  A< ! T K PT  s  t  a  t.  e :n ent.  ,  *  he  so 
g  a  t  e  c  a  1  1  e  r  s e  nd  s  the  results  . . !  t  n « • 
ACCEPT  i).K*k  to  the  sur  i  •••gut  e  ser.-r  ».  r 
Cede  r  e . 


Figure  4.  Distributed  Pseudo  Rendezvous 
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’  t-  r  i  i  c ) 1  i  t_*  i  *.  he  i  o  is  a  u  n  o  - 1  j  -  o  n  e 
’  j  i  i  s  p:  >  r  i  h' r  h* v  i *  e  t.  we  e  n  d  i  s  1 1  i  b  u  t  e  d  e  r » t  c  y 
-■  i  t>  o  aiva  :.;jn  tasks.  This  allows 

!  i-  if'iru  at  ror.ytc  sailers  just  the  sane 
-  asii  ;->rs.  Therefore:  each  calling 
1  s  ■  -  a  r.  k : ,  m  w  the  i  •  j  :i  i  q  u e }  a  d  d  r s  sot  its 
••  *  ’•)  -  J  - "  pr  --cedurt.-,  and  e-ash  surrogate 
'  /i : .  k  1 1  o  w  t  h  t.-  .  j  n  i  v.;  j  e )  a  d  d  r  e  s  s  of  if  s 
* . •  •  •  r  .  Add  :  t  ;  > na i ly  ,  e a ch  s  a r t og a  t  c a  1  - 
1  is.)  \j  r  o  o  e  dot  e  k  n  a  w  s  t  h  e  a  d  d  t  *_*  s  o  f  t  h  e 
:  •  i  r  r  :  >  j  a  t  e  s  r  vet  r .  i  s  k ;  each,  s  u  r  t  o  a  ate 
■  ’  e r  v e i  t  a: ;  k  k :  i  o w  s  t  h e  a  d d  r  e  s s  at  the  re  a  1 
'  r  v  e  r  t  a s  k  f  H  i :  i  t  e.  is  case. 

-  r'i  •.» d i  t  i  o n  to  the  pa  r  iiae  Lets,  t  h e 
r.  >.  s  a  a  j  e  s  s n  t  a  n  d  r  e  c  e  i  v  e  d  d  u  r  i  n  g  a  d  i  s- 
trib-iited  rendezvous  must  provide  for  com- 
:  lui  i  : at  ion  about  exceptions.  If  the 
.or  vet  has  art  exception  during  a  rendez¬ 
vous,  this  will  be  propagated  to  the  sur- 
t agate  caller  which  can  then  request  the 
s  .j  r  gate  server  to  raise  it  in  the 

:  .  j 1  t  . 

r  t 

:  g  u  l  r  •-.* :  i , 
w  it*,  a  n  c 
i  .  3  r  . 
in  w-.i.di 


- he  caller  is  killed  during  a  ren- 
the  server  will  be  unaffected  as 
but  the  subnet  may  be  burdened 
‘ssage  that  will  never  be  read.  A 
'or. merit  car.  be  made  about  the  case 
f:,e  .:ailer  dies  before  or  after 
s:v:  but  while  the  request  is 

t  r  j  n  s  i  t .  It  will  be  necessary 
connun i cat  ions  subnet  to  tine  out 
jns  ar.d  clean  up  any  remains.  Any 
o u  t  : heme s  will  be  a ppl  i  ca  t  i o n 


If  tin  surr  hi  at.  e  dies,  the  same  sort 
p  r  . : :  i  or  i  ex : . .  r  : . ;  c onmu  n i ca  t i o  n  is  eft  oc- 
vely  :■)».  •>!:.  However,  the  subnet  time 
\  will  ri  a  nd  I  e  this  cas  e  a  1  s  o  ,  a  n  d  the 
1  I  i  :i-j  tosk  can  oe  given  a  disconnected 


i . 


;  l  b  i 


.•  u 


in  the  case  of  a  r 
.reserve  normal  Ad a 


Lm- 


.*  ::v 
■  n  t. : 


f  »r 


,  when  the  tasks  involved  in  the 
us  .are  on  different  processing 
by  using  the  pseudo  rendezvous 
.  K  v  e  ri  t  h o  ug  h  e  a  c h  surrogate  task 
iur>  must,  be  coded  for  the  signa- 
f.  he  entry  being  handled,  the  cod  - 
ill  >t  tin.se  is  fairly  simple,  and 

l  V  U  1  1  r.J  t  c  . 


umn.a  t  y 


A.  I  J  *. 
P  t  * 


.Ur  . 

I';!!.'1 


-,yp. 


pap. 

>  f  r  i 


cue. 

Ad. 


ab¬ 


le  f 
i  ri  ? 


has  described  an  Ada  net- 
cited  s  y  s  t  e  m  d  o  s  i  g  n  e  d  t  o 
i  bu  t. ed  so  f  twa  r  e  concep  t  s 
t  or  real-  t  i  m  e  «_•  m  b  e  d  d  e  d  s  ys- 
I  i'.gua-je  contains  con- 
’an  ised  to  write  distri- 

c  1  s  o  s  u  ppo  r  t  s  iaa  n  y 
g  techniques  (e.g. 
pa  r  me  v  e  r  i  z e .  i  t  y  pe  s  , 


improve  tlie 
,  the  comp i I 


pja  i 
■  r 


o  1 


i  ssoc rat ec 
;  u  r  r  e  r.  1 1  y 


a 

c  h 


i  support  software  that  are 
available  have  supposed  that  a 
Ada  program  will  execute  on  a  single 
machine,  or  a  r.ul  t  i  process  i  rrj  system  wit 
a  shared  memory.  Thus  a  method,  called 
pseudo  rendezvous,  has  been  proposed  wh i 
will  allow  Ada  programs  on  different  pro 
cess  in j  elements  to  exchange  data  in  a 
manner  that  preserves  the  Ada  semantics 
a  simple  rendezvous.  This  allows  the  Ad 
network  to  be  implemented  within  trie 
project's  time  and  resource  constraints, 
and  will  support  the  evaluation  of  the 
performance  overheads  associated  with 
using  Ada  and  distributing  software. 
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DCP 


Th:  s  paper  dc-scr 


a  Di  st  nfcuted  S; 
cess,  DC?’. 


a:.::  procedures. 


Tr.e  DC?  is  b  se 


developing  reusal 


The  DCF  dev el 


EXPERIENCE  IN  BOOTSTRAPPING  AN  ADA  ENVIRONMENT 


STEVE  PARISH  AND  ANDRES  RUDMIK 


GTE  'A.noii  -V.  GUM',  P-V> 


ibes  eur  experiences  m  developing 
gftware  engineer i:iq  Control  Prc- 
rhe  DC?  is  a  portable  distributed 
support  environment  that  provides 
?ct  management  and  control  facili- 
vith  an  off-the-shelf  Ada  compiler 
svelopmer.t  tools.  A  coal  of  the 
*t  the  reuse  of  Ada  programs  and 
rapari-ity  is  supported  i r.  part  by 
=  which  maintains  descriptions  of 
cat.  be-  useo  to  *ocate  packages 
Ada  FDD  and  met node logy  is  being 
-port  the  development  of  reusable 
*ag-s  as  well  ~c  a  methodology  for 
:.s  from  exist. ng  packages.  The 
lability  is  addressed  by  building 
ss  to  the  user,  the  database  and 
rent.  The  development  methodology 
DC?  os  being  used  to  develop  the 
'.strapping  itself.  The  rr.ethodolo- 
s upper t ec  by  manual  controls  and 
as  the  DCP  capabilities  are  real- 
be  replaced  by  automated  controls 


TJC7IQN 


p  r  c*  g  r  a  mm  me  s  u ..  - 
is  self  con- 


uoer 


roach  is  Ghat  the  DC?  de¬ 
nser  s  and  can  learn  from 
developed .  Some  of  the 
dir.::  the  DCP  that  will  be 
are:  developing  systems 
il  interfaces  m  Ada,  de- 


compcner.ts  m  Ada,  designing  por- 
i  Ada,  an  Ada  PDL  supporting  reus¬ 
ability,  arid  methodologies  for 
Ge  and  portable  component s  The 


ipment  is  funded  by  the  WI5  JPM 
Directorate  under  contract 


experiences  described  in  this  paper  are  based  on 
aoout  twelve  mar.  years  cf  work  on  the  project  dur - 
mg  which  time  aorut  sixty  thousand  lines  of  Ada 
FDD  and  code  have  beer,  produced.  The  project  is 
expected  to  continue  for  another  year  during  which 
time  further  tools  arid  capabilities  will  be  devel¬ 
oped  . 

The  design  of  the  DC?  is  heavily  influenced  by  the 
need  to  provide  support  for  the  entire  software 
development  life-cycle  with  particular  emphasis  on 
managing  and  controlling  the  development  process. 
Much  cf  the  current  Ada  environment  activities  are 
centered  around  the  compiler  with  emphasis  on  sup¬ 
porting  the  code  development  phase.  The  DC F  sys¬ 
tem.  goes  beyond  the  Stonemar. -  requirements  ir.  that 
it  takes  a  broader  and  more  general  view  of  pro¬ 
gramming  environment s  as  embodying  and  supporting 
the  complete  integrated  process  of  program  design 
and  evolution  Stonemar.  section  l.J>.  The  DCP 
prc;ect  assumes  that  adequate  programming  support 
tools  will  be  available  and  that  they  can  be  inte¬ 
grated  into  the  DCP  with  minimal  effort. 

The  approach  taker,  emphasizes  the  maintenance  and 
management  cf  information  about  the  development 
process  and  the  objects  under  development.  Typi¬ 
cal  of  these  information  requirements  are  the  do¬ 
cuments  which  describe  the  system,  the  accuracy  cf 
these  documents,  and  the  identification  cf  reusa¬ 
ble  objects  such  as  packages  and  their  associated 
documentation.  Since  projects  tends  tc  reinvent 
objects,  the  DCF  places  a  high  emphasis  or.  sharing 
components  across  many  projects,  possibly  spread 
across  different  development  hosts,  and  possibly 
utilizing  differing  hardware. 

The  DCP  deliverable  is  a  s  stem  that  supports  the 
development  of  tools  and  applications  m  Ada.  Our 
approach,  tc  develop  the  DCP  was  to  manually  per¬ 
form  the  operations  whicr.  we  will  ultimately  de¬ 
liver.  This  has  allowed  us  to  exercise  the  DCP 
concepts  early  and  has  m  many  cases  allowed  for 
changes  prior  tc  development.  Also,  when  the  DCP 
capability  which  the  manual  process  has  been  sup¬ 
porting  is  developed,  the  data  necessary  tc  popu¬ 
late  the  DCF  database  is  already  available.  An 
example  of  this  is  our  use  cf  ADA  PDL;  each  pack¬ 
age  we  develop  contains  the  PDL  information  that 
can  be  extracted  and  put  into  the  database  when 
these  extraction  tools  become  available. 
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'  ADA  COMMAND  - - !  PORTABLE 

LANGUAGE,  MENUS,  j  NETWORK  1  VIRTUAL 
|  GRAPHICS,  HELP  ;  INTERFACE  I  INTERFACE 


I 

!  HOST 
|  DEPENDENT 
|  TOOLS 


DCF  DATABASE 
-  ENCYCLOPEDIA  i 
LI BRARY 


DIRECTORY 


DATABASE  INTERFACE 


CONFIGURATION  MANAGEMENT 


USER  INTERFACE 


TOOL  INTERFACE 


DOCUMENT- 
ION  TOOLS 


I 

:  DCF  TOOLS 


ADA 

COMPILER 


Figure 


1 . 


T.u*  II!  r.a s  a  lave red  arch.tectu re  as  illustrated 
-r.  F.cure  T:.r  near*  :i  the  DCF  is  a  database 

t.oa*  ma-nta-ns  an::  manages  information  about  the 
Ilf  us^rs,  : T:(-  or -eo*  *  ur.oer  beve loonier. t ,  and  the 
beve- opmer.  *.  proofs.  The  DCF  database  car.  be 
v.eweb  a  single  :er.- rally  ror.tr:  .  led  database 

mat  ion  ar.o  o.  ocumer.tati  or. .  A*,  tne  cataoase  ac¬ 
cesses  Will  oe  controlled  to  ensure  consistency  o t 
data  sc  that  a  DCF  user  car.  obtain  complete,  accu¬ 
rate,  and  current  descriptions  cl  applications, 
all  their  parts  and  the  relationships  between 
their  parts.  Conceptually,  the  DCF  database  can 
be  viewed  as  consisting  of  three  kinds  of  ir.forrr.a- 


Ar.  encyclopedia  which  maintains  descrip¬ 
tions  of  the  DCF  objects  and  relationships 
between  their.. 

A  library  which  contains  these  objects. 

A  directory  which  maintains  a  mapping  bet¬ 
ween  logical  object  names  and  host  depen - 
d e: . t  phy s i ca f 1 1  e  names. 


erate  documentation,  to  support  a.  development 
met  hod  clog*/*  and  to  enforce  pr:;ect  standards. 
The  encyclopedia  information  is  structured  to  sup¬ 
port  the  reuse  of  packages  ir.  multiple  Ada  pro¬ 
grams,  to  provide  information  to  support  their 
reuse,  and  tc  support  the  analysis  of  proposed 
changes  against  packages. 

The  DCF  library  objects  include  Ada  text,  document 
text,  and  the  data  derived  from,  these  text  forms 
such  as  object  and  load  modules,  and  completed  do¬ 
cuments.  The  objects  are  typically  stored  :r.  host 
files  using  host  physical  file  names. 

The  directory  allows  DCF  users  and  tools  tc  refer 
to  DC?  objects  in  a  host  transparent  manner  by 
maintaining  a  mapping  between  logical  and  physical 
file  names.  The  DCP  user  communicates  with  the 
DCP  using  logical  file  names  and  invokes  DCF  tools 
using  these  names.  The  tool  interface  is  respon¬ 
sible  for  converting  these  logical  names  into  phy¬ 
sical  file  names  and  then  directing  the  tools  tc 
operate  on  these  files.  The  DCF  has  adopted  this 
approach  so  that  the  system  would  support  a  dis¬ 
tributed  development  environment  where  the  user 
would  not  be  concerned  with  where  the  files  are 
stored  and  how  they  are  accessed. 


;..*:.  ,..i:  *  :>•  *»r.cy L.r.p*»-:io  ,  the  library  and  the1  di  - 

thpy  are  all  logically  part  of  a  single  database. 
These  terms  ar^  used  tc  provide  a  nar.cle  by  which 
different  categories  of  database  data  can  oe  ae- 
scr ibed . 

The  encyclopedia  mf rrnat : on  is  used  tc  manage  and 
■;-;r.*rr-;  the  c^nf  :  crura*  i  or.  cf  DC  f  objects,  to  oen- 


Surrounding  the  database,  there  :s  a  portable  da¬ 
tabase  interface1  that  allows  the  DCF  tc  be  ported 
to  other  hosts  where  there  may  be  different  but 
compatible  databases.  The  database  interface  will 
provide  uniform  access  operations  tc  all  of  the 
DCP  facilities,  and  a  standard  query  interface  tc 
all  DCP  users.  These  same  interfaces  can  be  used 
by  application  programs  tc-  provide  a  portable  ln- 
t  er  f  ac  e  to  apt  1 1 ca t : on  data a s e s  . 
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tap  of  the  database,  we  have  built  a  configura- 
n  man  a  cement  system  tc  ensure  that  all  appiica- 
ns  and  database  designs  developed  using  the  DCP 
maintained  ir.  a  consistent  form.  The  design 
the  configuration  management  systerr  uses  the 
abase  tc  manage  all  the  information  about  the 
stituent  components  of  a  document  or  a  program, 
figuration  management  tools  will  allow  users  to 


tc  add  components, 


f  etch 


me  a  cor.t  igurat i 
potent s,  store  components,  compile  programs 
These  tools  will  contain  logic  tc  ensure 
t  the  DCP  user  is  performing  a  valid  operation 
is  not  violating  the  project  development 
redures  and  standards. 

t  object  in  the  DCP  database  is  identified  by 
name,  the  revision  of  a  system  in  which  it  re- 


cat ion  number,  and 


test  and  development .  The  DC? 
provides  for  the  orderly  mcve-n 
ween  these  different  positions. 

The  cuter  layer  of  the  DCP  ;  roo¬ 
ter  face  to  the  DCF  users  and  tr 


TP 


sr.i  srr, 
bet- 


.  e  i  n  - 
The 


user  interface  supp 


Ft-  -  - 


t  h  e 


3  5  a 


po- 


mand  language,  a  full  screen  menu  system  a  help 
facility,  and  an  on-line  documentation  capability. 
Some  of  the  tools  are  host  dependent  and  will 
therefore  be  different  or.  each  host,  m  which 
case,  the  tool  interface  would  be  modified  tc  ac¬ 
commodate  these  tools.  The  DCP  user  interface  to 
the  tool  would  remain  the  same  with  the  only  dif¬ 
ferences  occurring  when  the  user  is  interacting 
directly  with  the  tool,  for  example  the  host  eci- 


DCP 
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views 
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subsystems  — 
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programs  - 
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create  - 
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delete  - 
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ete  pdl  extraction 


delete_wi th_relat :onship  -  I 
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execute 


fetch  - 

format  - 

genet at e_v:  ew  pacxaae 

modi fy_d esc r  ipt  ion - 

print  - 


XXX 


X  X  X 
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request_promotion  - 
wi thdraw_promot ion 
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ob  ject  s  and  their 
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tor.  Even  these  difference  car.  be  eliminated  m 
time  as  portable  tools  are  developed  in  Ada. 

The  initial  DCF  system  consists  of  tools  to  sup¬ 
port  configuration  management,  Ada  program  devel¬ 
opment,  and  an  Ada  command  language  interpreter. 
Some  of  these  tools  have  been  developed  specifi¬ 
cally  for  the  DCF  system  as  well  as  incorporating 
existing  host  supplied  tools.  Figure  2  is  a  ma¬ 
trix  of  DCF  objects  and  the  operations  which  the 
user  car.  perform  cn  these  objects.  An  operation 
is  identified  by  an  'X'  if  it  is  part  of  the  ini¬ 
tial  automated  DCF  system,  and  by  an  '  *  ’  if  it  is 
part  of  the  a  more  complete  system. 

Giver,  the  initial  DCF  toolset,  along  with  manually 
entered  and  controlled  data,  it  is  possible  tc  ex¬ 


ecute  a  stable  base  of  these  development  functions 
and  tc  build  incrementally  cn  that  base.  This  in¬ 
cremental  approach  demonstrates  the  viability  of 
the  DCP  design,  allows  for  early  use  and  evalua¬ 
tion  of  the  facilities,  and  supports  the  evolution 
cf  the  initial  system  into  a  production  quality 
product . 


Ever,  though  the  initial  system  is  not  complete,  it 
provides  sufficient  project  management  control  tc 
support  effective  development  of  medium  scale  pro¬ 
jects  such  as  the  DCP.  Adequate  information  is 
maintained  ir.  the  encyclopedia  to  track  the  const- 
ituer.is  of  a  change,  the  constituents  of  a  load 
module,  and  where-used  for  a  package  or  smaller 
source  c  ompor.  er  t . 

Cur  approach  tc  building  the  DCP  is  to  maximize 
*:.e  use  cf  off-the-shelf  tools  and  concentrate  our 
*  :  forts  on  building  an  integrated  environment  by 
::eve; opv.r.g  virtual  interfaces  between  the  tools, 
t..e  -so:,  and  the  DCF  database.  A  network  inter¬ 
face  will  allow  other  DCP  development  hosts  to  be 
: r f er connected  to  provide  a  distributed  develop¬ 
ment  capability.  The  distributed  properties  of 
the  DCP  will  be  fully  realized  when  the  distribut¬ 
ed  database  capability  is  available. 


DESIGNING  REUSABLE  COMPONENTS  IN  ADA 

The  DCP  addresses  the  goal  of  Ada  package  reus¬ 
ability  by  both  encouraging  the  development  of 
reusable  packages  and  by  providing  a  documentation 
database  that  supports  the  identification  of  pack¬ 
ages  for  reuse.  Our  goal  in  building  the  DCP  was 
tc  maximize  the  reuse  cf  packages  in  the  DCP  in¬ 
terfaces  and  tools.  Consequently,  the  design 
methodology  and  the  Ada  PDL  used  m  the  project 
emphasized  the  development  of  reusable  packages. 
The  following  is  a  description  of  some  of  the  les¬ 
sons  learned  ir.  this  project. 

Firs*,  Ada  packages  must  be  designed  and  document¬ 
ed  with  the  objective  of  producing  reusable  pack¬ 
ages.  Having  a  design  methodology  that  encourages 
the  development  of  reusable  packages  is  important 
in  that,  even  though  Ada  has  direct  language  sup¬ 
port  for  reusability,  it  does  not  enforce  the  con¬ 
struction  cf  reusable  packages.  Second,  one  can 
extract  from  the  package  text  information  to  sup- 
re:*  its  reuse  by  providing  data  or.  which  queries 


car.  oe  cased  tc  search  for  packages.  The  DCP  uses 
both  cf  these  approaches  placing  a  heavy  emphasis 
on  how  packages  are  designed  and  then  extracting 
the  necessary  information  from,  the  packages  tc 
build  the  encyclopedia . 


An  object  oriented  design  methodology  as  described 
by  Booch"  adopted  and  an  Ada  PDL  supporting  this 
methodology  was  developed.  In  developing  this 
methodology  special  consideration  was  given  to 
supporting  the  design  and  implementation  cf  resua- 
ble  packages.  We  feel  that  it  is  cf  ut  ost  impor¬ 
tance  to  design  packages  with  reuse  m  mind  if  the 
intended  objective  is  tc  reuse  them  ir.  ether  ap¬ 
plications.  This  approach  has  some  far  reaching 
implications  on  the  use  of  Ada  PDL,  the  design 
methodology,  and  the  documentation  support  tools. 
We  feel  that  an  approach  that  forces  the  designer 
to  develop  packages  that  implement  simple  abstrac¬ 
tions  with  well  understood  properties  is  the  key 
to  the  development  of  reusable  packages.  By  forc¬ 
ing  the  designer  to  categorize  the  kind  of  ab¬ 
straction  represented  by  a  package,  we  can  define 
guidelines  to  complete  the  remaining  package  de¬ 
sign  descriptions  to  conform  to  the  selected  cate¬ 
gory.  The  primary  advantage  of  this  approach  is 
that  it  produces  packages  that  have  well  under¬ 
stood  properties  and  that  are  singular  m  their 
function,  thereby  promoting  their  reuse  ir.  ether 
applications . 

Our  methodology  incorporates  the  use  of  structured 
comments  to  provide  additional  descriptive  infor¬ 
mation  in  Ada  PDL.  Some  of  these  comments  are  ex¬ 
tracted  and  stored  ir.  the  encyclopedia  to  support 
library  searching  and  for  documentation  purposes. 
We  are  currently  storing  the  following  kinds  of 
information  m  the  encyclopedia: 

1.  Package  category:  All  packages  must  be  ca¬ 
tegorized  into  one  cf  five  categories:  dec¬ 
laration  croup,  operational  abstraction, 
state  machine,  abstract  type  anc  abstract 
object . 

2.  Keywords:  Each  package  will  have  a  set  cf 

keywords  associated  with  it  tc  assist  : r. 
locating  packages. 

3.  Summary:  Each  package  will  contain  a  brief 
summary  cf  the  services  provided  by  the 
package . 

4.  Description:  An  expanded  description  of 

the  services  provided  by  the  package. 

:■ .  Data  Flew:  Packaaes  that  transform  data 
'operational  abstractions  and  state  ma¬ 
chines  will  have  data  flow  descriptions 
that  help  to  identify  and  describe  the 
transformations  performed  and  the  data 
types  that  characterize  these  data  flows. 

6.  Pac kaae  Specification :  Each  package  spec.- 
f  lead  or.  „«  a  documer.  *  t  r.a :  r  r  ;•  v;  :ie  5  ~  0: 

plete  and  detailed  description  c:  t  :.*•.■  :  a-:k 
age  including  the  data  :  yp.  s ,  ‘  h*  .  h 

tiers,  and  *  he  user  define-:  *  .  • 
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.here  <i r  ►  •  many  wavs  the*  f'T.cyc  .  uata  can  .  t- 
part.‘icned  to  support  the  searching  for  reusable 
software  components  and  documents.  One  such  ap¬ 
proach  is  through  the  use  cf  keywords  tc  caterer - 
.:e  packages  by  function  and  application.  Even 
though  this  seems  like  a  reasonable  approach  there 
are  some  difficult  problems  m  defining  a  set  of 
keywords  that  car.  be  used  to  describe  packaaes. 
Attempts  to  generate  a  standard  set  of  keywords 
have  run  into  difficulties  because  cf  the  comprom¬ 
ise  between  the  requirement  that  a  keyword  be  both 
qeneral  enough  to  be  widely  applicable,  and  spe¬ 
cific  enough  to  effectively  limit  the  search. 
Keywords  must  have  readily  available  meanings  and 
this  implies  maintaining  a  dictionary  of  valid 
keywords.  Also  to  be  effective  the  keywords  must 
be  validated  two  ways,  first,  against  the  keyword 
dictionary,  and  second,  against  the  code  they  de¬ 
scribe.  This  latter  validation  requirement  im¬ 
plies  that  one  can  check  consistency  between  the 
keywords  and  the  code  being  described. 

Another  way  tc  partition  the  encyclopedia  descrip¬ 
tions  of  packages  is  by  the  descriptions  of  the 
data  flows  from  a  package  to  its  environment. 
When  one  attempts  to  build  a  new  program  by  reus¬ 
ing  existing  packages  it  is  necessary  that  the 
data  flows  be  consistent  within  this  new  program. 
One  measure  cf  data  flow  consistency  is  that  the 
data  types  associated  with  the  data  flew  out  cf 
one  package  and  into  another  package  be  the  same. 
The  Ada  POL  identifies  the  package  data  flows, 
provide  a  textual  description  cf  the  data,  and  as¬ 
sociates  the  data  flows  with  Ada  data  types-  Some 
of  the  more  difficult  issues  that  must  be  ad¬ 
dressed  are  data  flows  that  result  from  the  use  cf 
relational  and  non-relational  files.  Ir.  this 
case,  the  designer  must  specify  these  data  flows 
in  the  package  specification. 


DESIGNING  PORTA BI. E  COMPONENTS  IN  ADA. 

Tne  DCF  is  intended  to  provide  a  portable  develop- 
me:.*  environment.  Portability  :s  taken  to  mean 
that  the  DC P  car.  be  easily  installed  or.  different 
htsts,  and  that  the  user  interfaces  to  the  DCF  :n 
a  consistent  manner  or.  each  host. 


as  separate  programs  we  must  provide  a  mechanism, 
to  allow  the  parameters  tc  be  passed  as  Ada  typed 
values.  A  problem  that  we  encountered,  was  that 
different  best  systems  provide  different  ways  that 
parameter  information  car.  be  passed  tc  the  invoked 
program:.  In  most  cases,  this  information  is 
passed  as  strings,  but  some  systems  may  impose 
restrictions  or.  string  length  and  ir,  some  cases 
content.  We  wanted  to  define  an  interface  to  the 
DCF  tool  set  which  would  be  host  independent  and 
ir.  addition  provide  Ada  type  checking  across  the 
interface.  We  identified  several  problems  that 
must  be  addressed. 

The  Ada  LRK  states  the  "each  mam  program  acts  as 
if  called  by  some  environment  task;  the  means  by 
wmch  execution  is  initiated  are  not  prescribed  by 
the  language  definition.  An  implementation  may 
impose  certain  requirements  on  the  parameters  and 
or.  the  result,  if  any,  cf  a  mam  program.” 4  The 
description  of  how  programs  interface  to  the  com¬ 
mand  language  must  be  described  m  Appendix  F  of 
the  Ada  LR.M,  which  defines  the  implementation  de¬ 
pendent  characteristics  for  each  A. da  implemer.ta- 
The  rrcbler:  that  this  raises  is  that  we 
cannot  count  on  the  compiler  to  support  a 
particular  program  invocation  protocol. 

The  DC?  solution  was  tc  define  sore  standard  Ada 
rackaces  that  will  be  used  by  each  DTP  tool  to  ac¬ 
cess  parameter  values  from  the  command  invocation. 
These  packages  would  hide  the  DCP  host  dependent 
representation  cf  the  parameters  and  provide  Ada 
type  compatible  values  to  the  program.  If  one 
uses  Ada  as  a  command  language  then  the  command 
parameters  are  typed  ir.  the  same  way  that  they 
would  be  within  the  called  program.  Type  compati¬ 
bility  between  the  command  parameters  and  the  pro¬ 
gram  command  input  is  preserved  by  sharing  the 
package  that  defines  these  data  types  :■  both  the 
command  and  application  programs. 

In  transporting  the  DCP  tool  set  tc  ether  host 
systems,  we  would  have  to  modify  the-  bodies  cf  the 
command  interface  packages,  but  net  the  programs 
that  use  them,.  This  approach  has  made  the  DCF 
tool  set  independent  of  the  particular  host  com¬ 
mand  parameter  passing  mechanism . 


T:  «■  :.  rcvides  a  ur.ifcrm  and  portable  Ada  devel  - 

ome:.t  environment  by  supporting  the  use  of  Ada  as 
a  design  language,  as  an  implementation  language 
c inn  as  a  command  language.  As  part  of  the  DCP 
pr:  •«?"*  ,  we  are  developing  a  portable  Ada  command 
language  interpreter,  that  allows  the  user  to  de- 
f  - rie  Ada  command  programs  m  the  same  manner  that 
he  w:._id  construct  his  application  program.  An 
advantage  of  this  approach  is  that  packages  can  be 
snared  between  command  programs  and  application 
frog rams  providing  a  consistent  development  envi¬ 
ronment  where  complete  type  checking  can  be  per¬ 
formed  between  command  programs  and  the  invoked 
application  program.  .  As  a  consequence  of  this 
approach,  the  DCP  presents  a  consistent  Ada  based 
environment  to  the  software  developer. 

In  order  tc  support  type  checking  between  the  com¬ 
mand  and  application  programs  which  are  developed 


Not  only  did  we  want  tc  be  able  to  port  the  DCP  to 
other  hosts,  but  we  also  wanted  tc  port  existing 
tools  net  necessarily  written  ir.  Ada  into  the  DCF 
system..  An  obvious  tool  that  needed  tc  be  includ¬ 
ed  was  an  Ada  compiler.  Ir.  attempting  tc  do  this, 
we  encountered  further  problems.  Different  Ada 
compilers  made  different  assumptions  on  how  the 
Ada  libraries  were  implemented  and  used.  Ir.  the 
DCF,  we  were  required  tc  support  multiple  versions 
of  the  library  objects,  with  multiple  developers 
creating  objects  at  different  development  sites. 
In  addition,  we  needed  tc  support  multiple  levels 
of  these  libraries  for  development,  testing,  and 
production.  Tools  were  required  to  retrieve  ob¬ 
jects  from  different  libianes  dependent  on  some 
search  path  specified  by  the  developer.  We  found 
some  of  the  existing  Ada  library  designs  to  be  in¬ 
adequate  to  meet  these  requirements  m  a  natural 
and  efficient  manner.  Tc  further  encourage  tool 
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pc r t aoi . i ty  and  transportability  tc 
different  project  management  environments,  it  is 
necessary  that  the  Ada  library  facilities  oe  gen¬ 
era*  and  flexible. 

S.r.ce  re  D_*  ma^es  extensive  use  of  a  oataoase,  a 
c.-'ir  per:  ar  .  l.i  ty  *  s  sue  was  develcrmc  a  database 

-  >  e  r  ? ,  arc  1 1  cat :  on  pr: grams,  and  database  adminis¬ 
tration  functions.  The  DC?  project  is  using 
Ingres,  a  relational  database,  for  the  encyclope¬ 
dia  since  it  provides  a  powerful  crsar.izat ion  cf 
data  which  is  capable  cf  modelling  both  hierarchi¬ 
cal  and  network  databases.  In  order  to  use  the 
database  we  nad  to  construct  a  portable  Ada  inter¬ 
face  . 

The  usual  approach  to  interfacing  a  programming 
language  to  Ingres  is  to  use  a  precompiler  which 
processes  specially  marked  statements  in  the 
source  and  generates  modified  source  containing 
calls  to  the  DBMS  interface  routines.  This  pre¬ 
compiler  approach  places  a  source  level  dependency 
on  the  underlying  DBMS  which  compromises  portabil¬ 
ity.  For  example,  each  DBMS  will  have  a  different 
form  of  database  directive  in  the  source  for  the 
precompiler  using  different  query  languages.  A 
solution  to  this  problem  is  to  define  a  standard 
DBMS  call  level  interface  to  be  used  by  all  tools 
and  applications . 

The  call  level  interface  was  achieved  by  examining 
the  source  level  expansions  produced  by  the  Ingres 
precompiler  for  ether  languages  and  analyzing  the 
data  dependencies  m  that  generated  code.  For  op¬ 
erations  or.  views  defined  :r.  ar.  Ingres  database, 
tne  only  data  sensitivity  is  ir.  a  retrieval  opera¬ 
tion  w:..;h  constructs  a  v*ew  one  attribute  at  a 
time.  In  Ada  we  wish  to  express  the  view  being 
processed  as  a  record,  therefore  we  have  developed 
a  fetch  operation  which  builds  this  record  from 
tr.f  individual  attributes  cf  the  view.  The  con¬ 
strue*. or.  cf  this  record  requires  knowledge  of  the 
mapping  between  the  view  definition  and  the  Ada 
representation  of  the  record.  All  other  opera¬ 
tions,  namely  insert,  update,  delete,  and  select, 
require  cr.iy  the  name  cf  the  view  and  are  not  sen- 
?:*  :v?  tc  the  data  content  cf  the  view.  One  of 
tne  DCP  tools  is  a  view  package  generator  which 
extracts  a  view  description  from  the  DCP  database 
ar.:!  venerates  ar.  Ada  package  supporting  that  view, 
a  retrieval  operation  cn  that  view,  and  an  Ada  re¬ 
cord  representing  the  view.  The  generated  view- 
package  addresses  the  data  sensitive  portion  of 
*  he  DBMS  interface.  This  package  together  with  a 
standard  DBMS  package  containing  the  data  msensi- 
’ -ve  iterations  forms  our  interface  t:  the  DBMS 


Each  DBMS  we  have  examined  either  provides  a  call 
level  interface  which  car.  be  used  directly,  cr  a 
r'ecorr.pi  1  e:  similar  tc  that  cf  Ingres  which  car.  be 
analyzed  ir.  the  same  way.  The  formal  parameters 
..see  in  -our  cal.  interlace  car.  be  translated  easi- 
y  * '  other  relational  DBMSs  eg.  Oracle,  I DM, 
DC  .  This  means  that  if  the  DCF  is  installed 
or.  a  machine  which  does  not  support  Ingres,  but 
has  anc* her  relational  database,  then  the  only 


code  requiring  rework  is  the  package  body  of  the 
call  level  interface. 

The  descr ipt ions  cf  both  the  DCP  database  and  user 
databases  are  held  ir.  the  DCP  encyclopedia .  Tools 
are  provided  tc  interface  with  the  underlying  DBMS 
tc  support  the  database  administration  operations 
such  as  defining  tables  and  views,  and  restructur¬ 
ing  the  database.  These  tools  provide  a  uniform 
user  interface  which  is  independent  of  the  lan¬ 
guage  of  the  underlying  DBMS. 

The  DCP  project  experience  indicates  that  tool 
portability  can  be  achieved  by  defining  the  appro¬ 
priate  interface  packages.  Our  approach  is  simi¬ 
lar  in  concept  to  that  defined  by  the  Common  APSE 
Interface  Set  'CAIS1*' 

Some  of  the  portability  and  transportability  prob¬ 
lems  that  we  encountered  were  due  tc  the  close 
coupling  between  the  compiler  and  the  Ada  library. 
In  conclusion,  great  care  must  be  exercised  tc  en¬ 
sure  that  these  interfaces  are  not  tool  technology 
dependent  or  that  their  use  does  not  significantly 
affect  per f ormance . 


EXPERIENCES  USING  ADA 

Even  though  the  DC?  system,  is  a  medium-  scale  pro¬ 
ject,  we  have  learned  a  number  of  lessons  that  are 
applicable  tc  both  medium  and  large  scale  projects 
and  we  have  identified  some  areas  for  further  in¬ 
vestigation  . 

Training  is  a  more  extensive  problem  with  Ada  than 
with  some  other  languages.  It  requires  a  consid¬ 
erable  amount  of  time  and  effort  tc  tram  program¬ 
mers  tc  become  proficient  in  Ada  and  m  the  use  cf 
object  oriented  design  methodology.  Most  of  the 
people  who  are  working  or.  the  project  had  a  strong 
Pascal  background  and  in  genera,  had  considerable 
programming  experience.  We  found  that  it  took 
about  three  months  for  these  programmers  tc  become 
fluent  m  Ada  and  able  to  think  and  design  effec¬ 
tively  using  the  powerful  abstraction  mechanism 
Ada.  Some  programmers  still  h.ve  problems  in  ef - 
fective  use  of  abstraction  concerts.  In  seme  cas¬ 
es  programs  were  overdesigned,  resulting  in  pack¬ 
ages  that  were  too  complex  and  very  inefficient. 
It  seems  that  it  will  take  considerable  experience 
before  one  car  make  effective  tradeoffs  between 
efficiency  and  elegance  in  design. 

Ir.  using  Ada,  there  are  a  number  cf  areas  that 
need  tc  be  considered  further.  For  example,  what 
design  methodology  and  design  discipline  must  be 
introduced  to  control  the  use  of  "with”  clauses  in 
structuring  programs.  In  the  past,  the  design  of 
the  program  architecture  included  the  specifica¬ 
tion  of  the  various  dependencies  that  program  mo¬ 
dules  had  on  each  other.  These  dependencies  were 
defined  carefully  and  controlled  during  develop¬ 
ment.  On  the  other  hand,  Ada  allows  one  tc  in¬ 
clude  "with"  clauses  on  both  the  package  specifi¬ 
cations  and  the  bodies  as  part  of  the  Ada  text. 
These  "with"  clauses  essentially  define  the  pack¬ 
age  dependencies.  A  development  environment  and 
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methodology  must  control  *he  use  cl  * h e  "with" 
clauses  tc  allow  t he  des :  r  t.:  proceed  m  ar.  or¬ 
ganized  and  centre  1  led  manner. 

The  aes.gr.  and  implementation  of  medium  to  large 
sca.e  software  systems  requires  more  additional 
support  than  is  normally  provided  by  minimal  Ada 
programming  support  environment .  Simply  the  fact 
that  a. .  the  Aaa  packages  are  under  ccr.f iguraticn 
management  control  requires  that  the  Ada  compiler 
must  provide  considerable  flexibility  o..  how  Ada 
object  libraries  car.  be  structured  and  maintained . 
In  the  DC?  project  we  encountered  a  number  of 
problems  where  the  compilers  view  of  the  Ada  pro¬ 
gram  library  was  toe  restrictive  for  the  DCP  task. 
The  DCF  requires  that  many  levels  of  Ada  libraries 
be  maintained  and  that  the  compiler  can  easily  oe 
directed  tc  the  appropriate  libraries  and  packages 
within  these  libraries.  Furthermore,  these  li¬ 
braries  may  be  distributed  between  different  host 
computers  requiring  that  the  compiler  library  in¬ 
terface  be  handled  by  the  DCF  tool  interface. 

Another  character: st ic  of  large  scale  development 
is  that  the  programming  support  environment  must 
provide  mere  support  for  documentation,  design  and 
implementation  to  ensure  that  these  program  de¬ 
scriptions  be  maintained  :r.  a  consistent  state. 
For  this  reason  the  DC?  encyclopedia  maintains.  Key 
design  information  that  supports  consistency 
checking,  impact  analysis  and  traceability  between 
various  development  phases.  For  example,  the  DCP 
database  tracks  the  use  of  data  types  by  identify¬ 
ing  the  package  in  which  a  type  is  defined,  and 
the  packages  and  programs  that  depend  on  that  de¬ 
finition.  This  concept  also  handles  the  tracking 
of  database  ’’views". 

Since  Ada  relational  DBMSs  do  not  exist  at  this 
time,  only  limited  Ada  type  support  can  be  applied 
to  the  database.  For  example,  in  Ingres,  only 
character  strings,  integers,  dates,  and  float  are 
supported.  Enumeration  types  do  not  map  to  data¬ 
base  implementations  since  the  action  of  the  type 
m  a  program  is  changed  when  a  new  member  is  added 
to  the  list  at  compile  time;  whereas  adding  a  new 
entry  m  a  database  would  affect  the  action  of  the 
type  as  a  run  time  operation. 

Another  database  problem  relates  tc  Ada  requiring 
the  unique  identification  of  a  type.  Several  com¬ 
mon  Ada  types  may  ex^st  in  different  relations  or 
views  in  a  database  and  it  is  difficult  tc  manage 
the  attribute  type  definitions  because  different 
programs  require  different  subsets  of  the  types. 
Two  extreme  approaches  are  possible,  first,  place 
each  discrete  type  in  its  owt.  package,  possibly 
without  any  operations,  or  second  place  all  the 
types  :r.  the  database  m  one  package.  The  first 
solution  involves  proliferation  of  "with"  clauses 
but  provides  good  granularity  against  change.  The 
second  solution  is  easy  to  implement,  but  unless 
aggressively  managed  is  expensive  in  recompila¬ 
tion.  Possibly,  the  best  approach  is  tc  be  aware 
of  the  underlying  types  needed  by  a  program  anc  to 
generate  a  packaae  for  each  program  based  on  the 
simple  types  that  it  needs.  Our  solution  m  the 
DCP  is  to  place  all  database  types  in  two  packag¬ 


es,  split  by  functional  requirements.  However 
since  the  view  pacxaae  aenerator  accesses  t.'iese 
types  when  generating  a  view,  and  since  package 

develop  the  option  which  customizes  a  package  -f 
underlying  types  on  a  rer-program  basis. 


D"?  DEVELOPMENT  EN V I  PON ME NT 


The  DCP  is  being  developed  using  a  VAX  11  "6  lo 
cated  at  Eglir.  AFB  Florida  running  VMS.  Two  96' ~ 
baud  lines  are  used  both  for  terminal  connection 
and  for  remote  printing  via  an  RJE  connection  tc 
an  IBM  mainframe.  The  Irvine  Ada  compiler  is  used 
for  development .  This  compiler  is  not  validated 
and  does  not  currently  support  full  Ada,  but  was 
chosen  because  it  supports  our  interface  to  Ingres 
and  has  a  more  flexible  library  interface.  Some  C 
and  VAX  macro  routines  have  beer,  developed  for 
system  dependent  operations. 


SUMMARY  AND  CONCLUSIONS 

The  approach  presented  m  this  paper  has  helped  us 
achieve  our  goal  of  building  a  portable  Ada  devel¬ 
opment  environment .  This  approach  included  the  de¬ 
velopment  of  virtual  interfaces  to  the  database 
and  the  host  operating  system,  the  use  of  a  data¬ 
base  to  manage  the  development  process,  the  devel¬ 
opment  of  a  methodology  including  ocject  oriented 
design  and  Ada  ?DL,  and  the  development  of  an  Ada 
command  language  interpreter  with  a  portable  typed 
interface  to  Ada  programs. 

Ada  has  supported  this  effort  well.  Where  tools 
or  capabilities  are  not  yet  available  interfaces 
have  beer,  successfully  implemented  tc  non-Ada  pro¬ 
cesses,  including  the  database,  the  text  editor, 
and  the  host  operating  system. 

We  have  addressed  the  software  reusability  goal  of 
Ada  by  supporting  a  methodology  for  both,  develop¬ 
ing  and  using  reusable  components.  This  methodol¬ 
ogy  includes  object  onentec  design,  and  the  use 
of  Ada  PDL .  The  DCP  provides  tools  to  extract  in¬ 
formation  from  design  specifications,  and  tc  popu¬ 
late  the  DCP  encyclopedia  which  provides  on-line 
documentation  and  supports  queries. 

In  developing  the  DCP  we  have  identified  some  po¬ 
tential  prod em  areas.  Ada  compilers  interface  tc 
t.oeir  Ada  libraries  in  different  ways.  which  can 
make  it  difficult  to  incorporate  ar.  arbitrary  Ada 
compiler  in  a  development  environment.  This  prob¬ 
lem  would  be  reduced  if  a  STandar-  method  of  in¬ 
terfacing  with  the  Ada  compiler  were  defined. 

Finally,  Ada  makes  grater  demands  cn  cieve’^;nrs 
than  some  other  languages  and  . t  takes  several 
months  before  developers  become  productive.  As  a 
consequence  of  our  experience  we  feel  that  more 
investigation  and  development  of  design  methodolo¬ 
gies  is  needed  to  better  understand  and  utilize 
the  Ada  language  concepts. 
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A  b  s  t  r  a  c  t 

‘This  paper  describes  tne  effort  to  produce  an 
Ada'  language  binding  to  the  Graphical  Kernel 
...stem  (GKS)  and  to  implement  a  subset  of  the  GKS 
■ „'v t lo^a 1 i ty  in  Ada.  It  presents  an  overview  of 
tn>-  :.r,S, Ada  project,  discusses  some  of  the  issues 
■lived  during  development  of  the  GKS  software, 
describes  the  results  of  a  post-coding  analysis 
comparing  the  binding  and  prototype  code,  and 
comments  on  the  lessons  drawn  from  this  experience. 


Introduction 

The  Graphical  Kernel  System  g'lFS)  is  a  pro¬ 
posed  national  and  i nternat iona 1  standard  for  an 
apt lication  level  interface  'o  a  graphics  system. 
GKS  provides  dev  ice- independent  support  for  most 
graphics  applications,  with  capability  ranging 
from  simple  output  primitives  to  complex  inter¬ 
act  iv>  iraphics.  The  set  of  GKS  functions  is 
intended  to  be  implementable  in  many  programming 
languages.  A  language  binding  defines  the  syntac¬ 
tical  interface  to  GKS  from  graphics  programs 
«ritter  in  that  language.  Bindings  to  ANSI  lan¬ 
guages  are  included  as  part  of  the  GKS  standard. 

.)  tandard  i  zat  ion  of  the  bindings  promotes  port¬ 
ability  of  both  programs  and  programmers ,  and 
facilitates  validation  of  an  implementation  of 

Of-'-  . 

’he  project  described  in  this  paper  was  part 
o*'  the  nul ti phased  GKS, Ada  effort  to  develop  Ada 
gr,. units  capabilities  conforming  to  standards 
currently  being  developed  by  the  American  National 
Standards  Institute  (ANSI;  and  the  international 
standards  Organization  (ISO;.  This  first  phase, 

, pc. r sored  by  the  World  Wide  Military  Command  and 
Cortrol  System  (WWMCCS)  Information  System  (W;S) 
Toinr  1  rograr  Management  Of'  ice  (JF'MO),  provided 
an  Ada  language  binding  to  the  Graphical  Kernel 
v Other  work  involved  development  of  proto¬ 
type  v‘  'ware  in  Ada  (both  device- independent  and 
dev 1  ,.e- dependent  1  to  demonstrate  the  capabilities 
.  t.'V.  ; '  Ada  system. 

*  Ada  is  a  registered  trademark  e*  the  li.s. 

Gove  ..'runt  -  Ada  ’oint  Program  Office. 


The  binding  was  developed  in  coordination  wif 
the  ANSI  Language  Bindings  and  Conformance  jutxo’i  't- 
tee  cf  the  Graphics  Technical  Committee  (X3H34I. 

It  was  designed  to  employ  the  full  capabi I i t ies  c‘ 
the  Ada  language  while  confomirg  to  the  specifica¬ 
tion  defined  in  the  GKS  standard.  The  attempt  to. 
synthps’/e  GKv.  and  the  Ada  mind-set  resulted  in  a 
few  difficulties,  tjhicn  were  presented  to  ANSI  as 
Ada  binding  issues  .  About  twenty  issues  were 
identified,  recorded,  discussed,  and  hopefully 
resolved.  Some  of  these  issues  may  be  categorized 
as  generic  binding  issues,  or  issues  applicable  to 
GKS  implementations  in  any  language.  Subsequent 
analysis  shows  that  some  of  these  issues  are  also 
appl i cable  to  Ada  mplementatiors  in  qerera! .  A 
few  of  these  Ada  language  issues  are  discussed  in 
this  paper. 

The  prototype  software  was  developed  on  a 
microcomputer  interfaced  to  a  graphics  monitor,  w •  t n 
a  partial  implementation  of  Ada  supported  on  mc 
development  system.  The  prototype  was  coded  en¬ 
tirely  in  Ada,  and  demonstrated  trie  feasibilit,  ot 
programming  graphics  in  Ada.  Both  machine-dope  d- 
ent  and  machine  independent  facilities  were  rvg-j i red 
in  implementing  the  software,  and  lack  Of  support 
for  full  Ada  presented  some  problems  in  the  develop¬ 
ment  effort.  The  prototype  code,  wnile  certain! v 
valid  Ada,  was  limited  to  the  use  of  those  language 
features  supported  by  the  compiler.  The  results  of 
a  post-coding  analysis  of  the  binding  and  prototype 
specifications  highlight  tne  differences  m  the  use 
of  the  language  under  these  two  approaches. 

Overview  of  the  Graphical  Kernel  System 

The  Graphical  Kernel  System  defines  a  set  of 
language-independent  functions  providing  s  standard 
interface  to  a  two-diiensional  color  qrcphi.s 
system.  GKS  supports  machine  and  device- independ¬ 
ence  in  the  production  and  manipulation  of  i? i c turns . 
yet  allows  device  turn  no  to  best  employ  tne  features 
of  a  specific  device  for  a  particular  application. 

As  a  standard,  GKS  promotes  portability  of  graphics 
programs,  facilitates  the  development  ot  applica¬ 
tions,  and  provides  guidelines  to  manufacturers  for 
future  device  capabilities.  GKS  supports  most 
graphics  applications  and  devices.  Types  of  appli¬ 
cations  for  which  GKS  could  be  employed  include 
CAD,  CAi  ,  management  graphics,  simulations ,  ..y. 
and  contouring.  Devices  whicn  right  be  interfaced 
to  GKS  include  plotters,  storage  tub*-  displays, 
printers,  digitising  tablets,  vector  refresh  c -IT '  , 

and  raster  CRT's.  Six  sets  ot  logical  m-eut 
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Basic  control . 
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'■'ultiple  normalization 
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1 

Full  bundles. 
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Metafile  workstations. 
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Segment  Storage. 
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MATRIX  Or  GKS  r UNCT IUNAL I T i 


GKS/Ada 

VS.  Ada  is  a  mul t  iphased  effort  to  develop 
ir,,;;h ic;  capabilities,  including  devel ouis.f nt 
jo  ANSI  standard  binding  of  CBS  to  the  Ada 
qua  O',  a  production-quality  implementation  of 
full  GrUj  functionality,  a  suite  of  ANS I  - 
rovid  metafiles  for  GKS  validation,  arid  a  suite 
dev ice-dependent  software  drivers,  'he  GKS/Ada 
ter  t,  orU'orrrs  to  the  set.  of  graphics  S  tandards 
rent  I ,  be i e  ;  developed  by  the  ANSI  Committee  or 
or -'at  ion  Processing  Systems  (X3). 

I  hi-  vi’.jjAda  system  model  'Figure  3.0-1 )  shows 
elnre’-t:,  of  an  Ada  graphics  system  and  rn- 
e *' ‘ a ;  s  between  ther-. 

An  A  da  appl  ication  program  must  access  'll  > 
v.i  Ada  Binding  interface  (ABI).  T h i  ' 

-  •  w,  i  .oef  err  I'-,  one  of  twelve-  level  '  as 
int-d  in  •>,.  ,m-|  API  standards.  The  ...tcS 

ei  ,-i'un-ie.  ir.i.  ludes  interfacing  with  t  ne 
*  ■  ■  1  I  ■  '  -  i  -  i  ■  I'  •ertii,.-  •' 1 1 1  and  Virtual  Device 
■i'  U  ,  U  .  a*  wh'.r  jr«.  dra't  ah's! 


f '  ■  .  I  •  **e  | nt  -I  t  a-.'  to  the 

n.ie-  i i  i ,-  i.e  i  v e -  f  he 

It-  :  r  ‘  j  1 1  Dev  lie  I  nt  c-rfaec 
i’-rh-:  endi  nt  lr-t  er  f  ,e  r  a!  a 
'  -  t  ’  :  r  1  i  t  /  t  han  nee  _  I’ll.. 


Virtual  Device  Metafile  provides  for  device-inde¬ 
pendent  storage  of  graphical  picture  information 
for  later  recreation  of  pictures  on  the  same  or  a 
different  system.  Metafile  generation  and  inter¬ 
pretation  are  accomplished  through  the  VDM.  A 
suite  of  metafiles  could  be  used  to  validate  a  GKS 
Ada  implementation.  Although  not  shown  in  this 
figure,  the  VD1  and  VOM  are  both  directly  access¬ 
ible  to  Ada  programs  for  use  in  other  graphics 
systems . 

The  accomplishments  of  Phase  i  of  this  effort 
included  production  of  the  Ada  Binding  Interface, 
currently  a  draft  ANSI  standard,  and  a  prototype 
implementation  of  GKS  to  Level  Da,  which  demon¬ 
strated  the  feasibility  of  the  GKS/Ada  concepts 
that  have  been  defined.  The  following  two  sections 
discuss  the  binding  and  prototype  in  more  detail. 

Ada  Binding  Interface 

The  major  emphasis  of  the  GKS/Ada  project  was 
the  development  of  an  Ada  language  binding  to  the 
Graphical  Kernel  System,  livery  effort  was  made  to 
embody  tne  philosophies  expressed  by  the  GKS  tand- 
atd  and  the  ANSI  Language  Binding  subcommittee  in 
developing  the  binding.  The  binding  consists  ot 
Ada  package  specifications  containing  all  of  tht 
data  types ,  subprograms ,  and  exceptions  used  to 
interface  with  a  GKS  system  implemented  m  Ada. 

The  binding  is  currently  an  official  work  item  on 


AN  s 1  and  ISO  agendas,  and  is  expected  to  undergo 
some  evolution  as  binding  and  language  issues  are 
resolved  by  these  standards  organizations. 

Medina  Philosophy 

The  fallowing  guidelines  were  applied  in  de- 

•  i n j ng  tni-  Ada  language  binding  to  'IKS ,  and  in 
attempting  to  choose  among  alternative  interface 
spec  i  f i cations : 

•  The  binding  should  be  transportable. 

Changes  required  to  rehost  an  imple- 
[■ontdt  ion  of  GK  on  a  different  system 
should  De  minimized. 

«  The  binding  should  be  extensible.  Up¬ 
grades  of  afs  should  result  in  minimal 
changes  to  graphics  application  programs 
and  GKb  implementations. 

•  I  he  binding  should  support  the  GKG 
level  concept,  with  the  interfaces 
for  eu< h  level  upwards-compatible. 

•  The  binding  should  Support,  portability 
of  gpp  iioat  ions  programs  us  '  :  Ghu. 

:'rngrjrs  might  use  any  imp  1 . -  rotation 

of  f,i.s  with  minimal  changes  to  the  source. 

I  eatcr'es  of  the  Ada  language  should  be 
uod  to  support  portability. 

•  The  binding  should  follow  the  semantics 
Of  the  •indarri  wherever  possible. 


*  The  full  capabilities  provided  by  the  Ada 
language  should  be  used  to  best  advantage, 
with  compatibility  with  Ada  Philosophy  used 
over  some  other  method. 

•  The  binding  should  be  as  sirilar  as 
possible  to  other  language  bindings  tc 
promote  programmer  portability. 

These  goals  were  not  always  mutually  obtain¬ 
able,  and  involved  trade-offs.  Many  of  these  or 
similar  issues  are  discussed  in  . 

Binding  Sjieci  fixation 

The  mapping  of'  GKS  into  Ada  was  fairly 
stra  iohtforward ,  although  the  GK.s  specification 
incorporates  some  features  which  are  in  conflict 
with  the  Ada  language  philosophy,  for  the  most 
part,  these  areas  of  potential  difference  were 
recognized  by  the  GKb  developers,  anti  allowance- 
made  for  variation.  The  approac  taken  ir  .invert?:  - 
men  t  of  the  Ada  Binding  Interface  .  A  ft )  is  ;  Re¬ 
sented  for  the  general  categories  of  data  ly;  mg. 
f uct iona  1  i ty ,  error  handling,  packagin':  and  naming 
conventions . 

Mapping  of  GKb  Data  Types_  to  Ada 

I  he  most  difficult  part  detir.-rq  the  Ada 
language  binding  rested  in  the  area  of  dut  i  typing. 
The  GKP  standard  del  inert  several  simple  and  ■ 
pound  data  types  used  in  describing  the  sc  i-  ins 
ot  th.-  GKP  functions  and  data  structure-..  ihe  e 
data  type's  were  implemented  as  a  variety  o*  Ada 
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*n..  , l.  :  '  *  .1  r  _ 

'-it:  i  ■*  f .  »'*  ■  LOUvrf't  U!':s  V|  (Kit:  type  •  <r  ► 

•  ov'ideb  tv  the  stands  *  0 .  I  hr  *  i  ,.y '  *  •  • ,  ,rd  .vf-'S 

ted  4  Or  !.ons  1  stei’cy  *  i  t •  •  •.  .j  •.»_•:  *..r 

jMi.  r.  juris  .  f  jr'ii."  t  *_>.  r  ? ... 

•  on \  i  s  tency  t  h rou a rou ?.  t  h»  0  i •  o  1  ■  •  . .  *. s ,  v  i  : 

!  I  With  delta  tVCe  0a" e\  ,  i!-0  tf  D*  ■  !«  1  f  - 
e*  ou  :h  tor  urn  ir  The  p.:d»  ..f  m-  *  e  \  ■  ■  •  . 

Other  narin-.j  issues  i.m’Icv:  m-  ! •  •  •  <•* 

ion  nuniei  s  in  pdckaoe  r-- a i- =* . *_  im.  v  r--  =  lj l-.i  no* 
ible  conflict  of  GkS  n»nrs  me  a-  ,  .--h 

.t ;  • 1  mat  i  or;  prop  re."'-  ''don't  *sue  l  m-  A- 

iije  : ,  and  use  of  abbrevi-it  U:r,\.  ,o  .«:  Ll« 54  sh¬ 
it  ten  has  dot i nod  a  sot  rf  standard  aht>»>-.!a- 
s  to  be  used  in  ali  ; cin.;  4.-1  ie  hir-dinr  .  ,rc?  a 
uo.;t-  i  ike  Ada,  abbrev 1  At  ides  are  rot  required, 
l  *■  ,  -,ed  ,  they  rust  be  j>,  i f  en  1  v  c.  ons  i  -.  tent  with 
-ilb"  ev  :  at  ion-,  de*  i  n.-d . 

■,  c  ■  Ki  f  i  on  o4  t  he  i  •  i  nd  i  no 

is..*  r\:  thr-  de veloprent  of  the  Add  la sou doe 
e  :  to  r  ,  a  nui'iber  of  issues  were  identified. 

4  v-e  ; 1  jos  were  discuss*  ’  by  the  A  A  a  1 
.«.<:*■  subcoinni  t.  tee  anci  other  interested 

•  ,  o  o  tentative  resolutions  were  reached'-'  . 
f  r i s '  ,.»os  car-  be  classified  as  'meneiit 

:u.  1  or  issues  which  are  applicable  to 

e  ;u  «  •»  ?'• '  r.d  i  n;]s .  The  resolutions  which  have 
ido-med  tor  the  Aaa  bindim;  will  be  used  as 
■  >■  :2<  .  !  ,  ions  m  develop :  no  bindin.s  to 
a*  !  lei  sjcn  as  based!  and  :  A  ,  1). 
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input  output,  and  is«-fcn-ie 


m” w  sha’sies  wr-;.„h  have  be*-f  : . -..i • : ■  ;ested 
‘an  ■  r ?  ■  v  t  l  te  rati  on  o  f  t.he  Ada  b  i  fid  l  no  a  rf  : 

A  i  i  ow  i*»:p  ler'entat.  ions  to  define  the 
: '  r  ‘*r  face:',  for  l scapes  an.i  Aener'a  1  i /r-d 
i.  r- a ,*v i ■ ,  ;  br  j..  i  t  j  ves  ,  and  LC'Uai*’  the-  ir. 

.  i ■(■<:  i  +‘ i  c: a t  ; r  o  f  a  ; -a ka -.in  Ar. .'>  ! AN’iJArl; . 

which  would  contain  i  ”ui  1  < -r  enta  tinn-de:  endeot 
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wor  1  (1  suord  i tm 4  »•  .,e as^-nt.  na;  if  S,  and  coin* 

table  indices  ar*-  f  n*.  joviiblr 
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ff  Ut'.UL  attribute 


•  . :  . ■  ’  *  i r,:i.i  i  !>■  t  uni  t  i ons . 

::  ’!■■  .  *  ’  r*  ■  y  s ter  : r.i.  1  jilt'd  0  single 

■  .  ’  v.itr:  sixteen  predefined 

■  .  ,■  i  tive  marker  types,  two 

:•  r  r  .t  r  a c  t  *■  r  -onls,  one  line  width, 

■  ,  and  ^ettible  bundles.  I  he 

.  i  .  :  .  .iuj  not  provide  any  settable 

: ■  1. 1 •  i ’  j.-,  "ltetture  tor  the  GkS  system 
,  :  ■  *  -  -e  jedte  packages  were  oe- 

■  1  ■  ’  ■  !  I  '  *  *  ■  *  s1 :  1  owl  no  : 

•  ■  ;  rr.it ,  r  :  .*.ite,  one  per  system, 

»>•,.  .  ij,  ,  t  v.i  1  Ur’  o*  the  opera ti no 


#  ,•  script ien  Table,  one  per  system, 

p'orisation  about  availability 


•  tut.-  !  1st,  one  per  system,  holds 

' r.  ..late  of  workstation  i ndepend- 

••••*.  '  *cr"  at.ion.  In  a  full  implementation 

'  ,*’i,l  ist  also  includes  the  input 

•  1’"  workstation  Description  Table,  one  per 
workstation  type  available  in  the  iniple- 
•••■•tatinn.  describes  the  capabilities 

•  •  •  i*  i ->n .  T n i  table  cannot 

be  changed  by  an  application  program. 

•  Tre  workstation  State  List,  one  per 
every  open  workstation,  contains  the 
turn  t  settinas  of  workstation  de- 

:  endent  attributes. 

•  The  i.rror  state  list,  one  per  system, 
'Detains  information  including  the  current 
error  state. 

I  he  Geo  device  'ndtpendent  software  was 
■1.  ■  '  oted  concurrently  with  the  development  of  the 
•el;  edini  interface,  but  the  AB1  specification 

■  e., ,  i'-ed  "'edification  to  conform  to  limitations 

i  :  b,  the  compiler.  For  example,  the  binding 

ih",  the  type  of  an  opject  from  the  Normal  ized 
.O'.’’  3  n«*e  i.vstei"  as  follows: 

VsL  'VDL  is  digits  PRLCISION 
’  ar  ;e  .1.0.  .1.0; 

'he  ‘r.l  lowing  de«  laration  had  to  be  substi- 
'■  r  the  prototype  .ode,  since  programer- 
d‘  * i red  floating-point  types  were  not  supported: 

...bt/pe  N'iL  rye;,  is  float, 

the.  data  typing  facilities  which  were 

■  •  1  sfed  but  not.  supported  included  integer  type 
definitions,  derived  types,  record  typing  involv¬ 
in'  discriminants,  and  array  aggregates.  We 
'‘■re,  a  i  !  ,  re]  ;f.(j  on  the  predefined  data  types  and 
‘  i 1  ' ‘.a  i  i  y  ■  'strained  arrays  to  work  around  the 


problems,  although  the  semantics  of  ttieir  use  was 
inconsistent  with  the  intention  of  the  binding 
specif ication.  Limitations  on  symbol  table  si/e 
also  presented  problems  in  attempting  to  compile 
GKS  as  a  singl  package.  We  ended  up  dividing  GKS 
into  five  separate  packages.  Ore  package  contained 
all  of  the  GKS  interface  dafa  types,  and  each  of 
the  others  contained  a  subset  of  the  GKS  functions. 

Device  Dependent  Software 

The  device  driver  software  interface  was  de¬ 
signed  to  prototype  the  capabilities  of  a  draft 
standard  for  tne  Virtual  Device  Interface.  The 
prototype  VDI  contains  routines  for  initialization 
of  the  workstation,  clearing  the  screen,  drawing  a 
line,  drawing  a  hollow  or  filled  rectangle,  drawing 
a  hollow  or  filled  circle,  displaying  a  marker,  and 
writing  a  I i ne  of  text. 

The  device  driver  software  was  translated  into 
Ada  from  existing  programs  written  in  the  language 
C.  This  code  performed  the  machine  and  device 
dependent  functions,  such  as  initializing  values 
of  registers  and  memory  addresses,  defining  bit 
patterns  for  character  sets  and  line  styles,  and 
performing  data  format  conversions. 

The  package  SYSTEM  was  incomplete,  and  hard¬ 
ware  addressing  had  to  be  accomplished  through  the 
use  8086  package  supplied  by  TeleSoft.  We  also 
had  to  work  around  the  lack  of  representation 
specif ications . 

Language  Issues 

This  section  discusses  issues  identified 
during  development  of  the  GKS/Ada  software,  and 
which  may  be  applicable  to  various  Ada  applications 
and  other  Ada  standardization  efforts. 

extensions 

It  is  the  capability  in  Ada  to  declare 
"programmer-defined"  operations  that  prompts  this 
issue : 

Should  the  binding  (or  other  interface) 
provide  for  the  definition  of  basic 
operations  appropriate  to  the  data  type, 
but  which  are  properly  extensions  to  the 
functionality  required  by  GKS  (or  other 
i nterface  requirements ) ? 

examples  of  such  operations  from  the  GKS 
binding  are: 

function  "  +  "  (l.tFT,  RIGHT  :  POINT) 
return  POINT; 

f unction  IS  IN  ( 1TLM  :  ITEM  TYPt; 

THL  LIST  :  LIST  OF) 
return  Bliul. LAN ; 

Unless  the  data  type  is  private  or  limited 
private  (in  which  case  all  needed  operations 
should  be  provided),  the  user  ot  the  type  could 
define  his  own  routines  for  performing  such  opera¬ 
tions.  However,  it  is  advantageous  to  standardize 
common  operations  for  purposes  of  portability. 
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T  n  t  *  advantage  is  of  t  set  oy  the  additional  burden 
tv’:iu'  !  s  ;  laced  on  the  developers  and  "  a  int  j  i  r u_  t  s 

or  ■•sen  interface  specifications. 

Another  issue  regarding  non- roqu i red/ 
ir’pl  trier? a  t  ior-def  i  tied  extensions  : 

should  such  interfaces  allow  the  intro¬ 
duction  ot  ’or;- regu i red  and  implementation- 

■:1e  f  :  «ed  opera t  ion',? 

Examples  fror  the  Ada  binding  include: 

possible  operations  on  objects  of 

type  GKbM  ITEM  TYPE 

new  Escape  functions  or  Generalized 

Gnawing  ;>ri:’:i tives 

If  these  declarations  are  allowed  in  the 
specification,  then  it  is  no  longer  "standard"  for 
purposes  of  validation.  An  alternative  which  is 
attractive  for  the  Escapes  and  GDP's  is  placing 
then  in  an  external  package.  However,  forcing 
operations  on  private  types  to  be  in  an  external 
: acka  le  doesn't  mesh  with  the  concept  of  encapsu¬ 
lation  of  types  and  operations.  It  also  makes 
imp  1  e'‘ientdtion  of  the  operations  awkward.  Another 
alternative  is  to  have  such  extensions  contained 
in  a  package  EX' LNS IONS  within  the  package  of 
rcto-y-nj  .  This  way,  the  user  of  the  extensions 
rust  pref i »  every  use  of  the  element  with  the  word 
:  v  ;NS!iiNS.  or  must  explicitly  indicate  use  of  the 
exit. '.j  ions  throu  ;h  a  "use"  statement  '.this  is 
nicer  fc*‘  overloaded  operators).  rhe  problem  or 
risibility  of  the  declaration  of  private  types  is 
a 'so  solved. 

exceptions 

Current  practice  suggests  that  a  minimal 
'■•umber  of  different  exceptions  be  declared  by  a 
program.  The  philosophy  of  GKS  suggests  that,  the 
preciseness  of  description  provided  through  a 
large  number'  of  distinct  exception  conditions 
nutwei  |hs  the  disadvantages  of  dealing  with  a 
large  ryrber  of  possible  exceptions. 

which  is  preferable,  and  under  what  circuin- 

'.■fdni  es  ? 

An  example  from  the  binding  in  which  consol  i- 
dation  of  many  error  conditions  under  one  excep¬ 
tion  is  desirable  is  the  state  error.  GKS  defines 
>  ight  possible  cases  in  which  a  state  error  would 
be  reported,  each  treated  separately  by  GKS.  Dur¬ 
ing  execution  of  an  Ada  graphics  application  pro¬ 
gram,  if  any  one  of  these  state  errors  were  to 
occur,  if.  indicates  a  serious  logic  error  in  the 
program.  Exception  handlers  would  have  to  check 
for  all  eight  of  the  exceptions  to  detect  if  a 
state  error  had  occurred,  it  is  suggested  that  a 
.ingle  exception,  STATE  iRROft,  is  more  appropriate. 
It  s sou  Id  be  noted  that  because  of  the  way  in 
which  GKS  defines  error  handling,  the  error  hand¬ 
ling  routine  would  have  no  way  of  knowing  the 
context  in  which  the  call  causing  the  error  was 
made,  and  must  treat  errors  uniformly.  In  Ada, 
the  programmer  determines  the  context  in  which 


t  ho  exception  njtidli-r  exist,.  There  some  ’ ;  m, 

0*  m'ot  "dtion  in  us  ire  the  pres  riperi  pre.e  r. 
sin.  e  t  re  (•■let  state  error  is  net  i.i'Cni  .  7ri" 
seems  tu  be  a  problem  with  exceptions  it:  ,vi .  •  a  , 
the  exception  which  is  detected  by  a  o  p  a  ra, 
not  express  the  true  nature  of  the  cause  s>  the 
error  condition. 

Data  Typing 

Which  approach  better  promotes  portability  of 
Ada  programs,  use  of  programmer-def ined  data  types, 
or  predefined  data  types? 

For  example,  a  program  could  choose  between 
the  declarations: 

type  NUMERIC  TYRE  A  is  new  F LG AT  ; 

type  NUMERIC  TYPE  B  is  digits  RRLCISI j', , 

A  program  which  uses  "is"  is  not  guaranteed 
that  PRECISION  digits  of  accuracy  are  supported  by 
every  implementation.  "A"  is  guaranteed  to  have 
some  implementation  on  every  machine,  but  a  ; i ver 
implementation  may  not  be  appropriate  to  the  needs 
of  the  urogram.  Another  consideration  is  that  "E 
is  implemented,  but  in  an  inefficient  way.  it  is 
assumed  that  "A"  would  employ  the  most  efficient 
imp  1 omenta t ion . 

Another  issue  of  interest  is  tightness  of  data 
tyo i ng . 

How  strongly  typed  should  GKS  (or  another 
; i  ter*  act  )  fit1? 

It  is  possible  to  define  the  GKS  function 
Parameters  in  such  a  way  that  a  maximum  amount,  of 
checking  be  performed  on  parameters  and  other  data 
objects.  Emphasis  i;  intended  on  detecting  logic 
errors  at  compile  time,  but  run  time  checking  would 
also  be  performed.  The  strong  data  typing  of  Ada 
allowed  us  to  of  f- load  check i ng  for  many  of  the  GKS 
errors  on  to  the  compiler.  This  seems  to  be  a  good 
thing,  but  in  order  to  implement  it  to  the  maximum 
extent,  the  binding  would  be  lost  in  a  sea  of  data 
type  declarations  which  would  be  confusing  at  best. 
There  are  two  points  of  view  to  consider  as  well. 
The  application  program  desires  assurance  that  the 
function  performs  as  promised,  and  the  GKS  imple¬ 
mentation  must  always  check  the  validity  of  the 
parameter  values.  Both  desire  to  u» t'-load  as  men 
checking  as  possible  on  the  compiler. 

Another  consideration  is  "who"  detects  the 
error.  For  example,  the  value  of  an  integer  t.vce 
parameter  should  fall  in  the  range  1..S.  'he  type 
ot  the  parameter  might  be  a  subtype  declaration 
which  restricts  to  this  range.  In  this  case,  a 
value  outside  that  range  would  be  raised  as  a 
CONSTRAINT  ERROR  exception  to  the  calling  unit, 
and  the  called  function  never  gets  control.  Al¬ 
ternatively,  the  type  of  the  parameter  could  to 
left  as  an  integer,  and  the  value  of  the  parameter 
checked  on  entering  the  function.  In  this  case, 
the  function  could  raise  a  more  descriptive  and 
distinctive  exception,  such  as  INDi  X  INVALID. 
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;  Mappir=.j 

~nf  ;  ■  spec  1 1"  i  cat  i  m  Jefir,s  several  func- 
’  .,  - w-icb  employ  a  parameter  wu  >  i-Ufitents  are 
;  r t  ■  r;  reted  d i  f  ferent  1  y  based  -  trie  value  ot  a 
5L^'.  "d  ;  itF'd'  eU't',  or  ‘  hr  value  ‘  ore  ot  r.r-,  oi" 

:  >  t j  r.  d  ot  t ate  par:",  fee  ‘.v:  L  a  1  ]  tot  -  a  data 
rrO'i;  ; .  T  rj-  ■  -  arc  .ever  .1 1  lions  : 

•  ?•'■*  jti'a  a  sin  tie  function  jam  ;  a  •  ; ;• ;  1  c 
data  ''‘0.00(1  tvpe  \vjon  is  a  st  r  ir.g ,  , 

wr  it.-'  "as  a  car;  U-x  in$grpretat ion. 
mi  .  volution  also  in: lodes  me  use 
ot'  private  lyses,  with  associated 

.  r  r'.i  t  i  Oils  . 

•  rvf  ir.e  a  single  function  us  in.;  a  complex 
data  record  type  (such  as  a  record 

witn  disc  ininant  components  and 
variant  parts),  which  has  a  simpler 
i nte roretdtion . 

•  ’  vet-load  the  function  using  the  specific 
data  record  types  needed. 

•  :v;nide  multiple  unique  functions  using 
the  specific  data  record  types  needed. 

since  it  is  likely  mat  the  structure  of 
tnc  data  record  will  change  over  the  life  of  the 
s.sr.e:',  or  that  t"e  structure  will  vary  greatly 
ever  various  r pi ■ rentat iors ,  the  second  option 
was  discarded.  The  third  and  fourth  option,  were 
'1:  (  1  :t  •••  her. ,■  scary  to  be  abl#  to 

inyume  the  contents  of  the  data  record  without 
Knowing  in  advance  what  the  structure  looks  lice. 
This  left  us  with  the  first  option,  and  whether 
to  use  strings  or  private  types.  It  made  sense 
to  be  Ada-like  and  opt  for  the  private  types,  and 
define  functions  for  accessing  the  components  of 
the  various  data  records.  Problems  with  this  are 
that  an  ordering  is  implied  in  calling  the  func¬ 
tions  to  dt  terrine  which  of  several  possible  com¬ 
ponents  may  be  accessed  (similar  to  variant  parts 
o*  records;.  The  semantics  of  this  ordering  are 
not  in’isit  in  the  definition  of  the  functions 
a-,  tru  e  are  with  -hr  visible  record  type  declara¬ 
tion. 

Tool  Support 

me-  rioD  position  that  there  shall  be  no  Ada 
,uh,ets  avoids  the  problems  associated  in  bind  inn 
1  •i'h.pj'iges  Pke  FORTRAN  and  PI / 1  (in  which  autho¬ 
rized  subsets  exist) ,  requiring  alternative  bind- 
mp.  for  the  same  language.  However,  current  Ada 
err’;  iters  support  the  Ada  language  to  varying 
■I- pees,  cf  completeness,  and  it  may  be  some  time 
:.t‘ure  validated  compilers  art-  available  for  all 
"  mm  i nes  which  could  support  OKS.  it  will  be  even 
1  on r  before  all  these  features  are  implemented 
: an  efficient  manner.  One  solution  would  be  for 
fools  such  as  GKS  to  employ  only  those  Ada 
‘natures  which  are  implemented  by  all  compilers  . 
'his  approach  would  preclude  use  of  generics, 
aggregates .  overloading,  or  tasking.  Use  of 
i  ungtj ,  feature",  outside  of  that  subset  would 


inhabit  the  portability  of  both  s-.:  1,  eetat  ions 
o'  ',L.o  and  of  application  pro  pa:  ■-  wrim’  ,e  'it  . 
The  binding  defines  the  use  of  all  o‘  t '-,c 
features  except  tasking.  The  prutot  /;  e  : -p  1  c  ta  - 
lion  described  in  this  paper  is  out  of  many  .iit.  r- 
nate  mappings  ct  the  GKU  bird  in  ;  to  *  it  the  1  >~i  ta¬ 
ttoos  of  a  compiler.  The  position  e.xprt  s  a  g  1:. 

AN  j  1  Xc-Hs  is  that  the  fulfr-st  possible  deficit:'  r 
fur  the  language  should  In  a.-d.  It  :,houl<:  bf 
recognized  that  certain  *•*.«'«  tea*.  ’  u's  ore  "ec r  ,  ,u >• , 
in  the  in  ter  in  arid  will  hi  rider  eft  t  f  r.o  vt-t'fv 
i  ont on:, ante  o(  an  imyl eisentat  ior.  t  the  ,*.  v  d at  r. . 
However.  the  Ada  'oint  Program  i-‘*  n:e  (A  " 
predicts  at  least  six  validated  .  •:(  i let's  I.  •  id- 
T%4'.  Inert,  should  be  more  than  sut  t  i,.  lent 
support  for  Ada  as  GKs  implemei.tdt  ivtis  PecO" <• 
aval lable. 

The  use  of  a  compiler  wilier  does  not  provide 
the  full  capabilities  of  the  language  would  result, 
in  the  inability  to  Implement  the  system  as  in¬ 
tended,  or  to  exploit  the  power  of  the  language  as 
it.  was  designed  to  gain  the  benef  its  of  reliability, 
extensibility,  etc.  A  comparison  of  thr  data  type 
distributions  in  the  binding  and  prototype  specifi¬ 
cations  highlights  the  differences  in  the  utiliza¬ 
tion  of  the  Ada  language  features  in  order  to 
accommodate  the  subset  compiler  (Table  4.4-1;. 

Host  of  the  differences  are  in  the  use  of  pre¬ 
defined  versus  programmer-def i ned  data  types.  Use 
of  generics  in  the  binding  allowed  the  implicit 
declaration  of  many  additional  data  types  through 
instantiation  of  packages  for  coordinate  systems 
and  list  man  i  pul  at  l  or  facilities.  Because  getirrus 
were  not.  supported,  corresponding  data  types  had  to 
be  expl icity  and  individually  declared  in  the  pro¬ 
totype.  Many  of  the  types  provided  through  the 
generic  instantiation:,  are  not  necessarily  used, 
however.  The  table  is  limited  to  data  type  decla¬ 
rations  from  levels  n.a  and  Oa,  since  that  it  the 
level  implemented  for  the  prototype.  The  full 
binding  utilizes  record  types,  private  types,  arct 
enumeration  types  much  more  heavily,  as  shown  in 
Table  4.4-2. 

Conclusions  anti  Recommendations 


The  following  conclusions  can  be  drawn  from 
tms  experience  witn  Ada  for  the  Graphical  kernel 
System: 

•  Ada  may  successfully  be  used  to  program 
graphics  applications  at  both  the  machine- 
dependent  and  machine- independent  levels. 

•  Graphics  programmers  from  various  appli¬ 
cations  areas  should  consider  use  of  the 
Ada  Siinding  interface,  and  to  report  any 
problems  with  the  binding.  The  applica¬ 
tion  programs  which  were  written  to  demon¬ 
strate  GkS/Ada  were  written  to  interface 
with  the  prototype  specification,  and  tile- 
interface  has  not  yet  been  fully  tested. 

•  GKS  should  be  studied  tor  possible  use 

as  part,  of  the  GAIN,  includin','  compatibility 
with  the  CAIS  definition. 


82 


L: r  d  i  r  g 

'  I-'c’ -a irt,  9e,:erical1y 


1  r 

di-d 

■  s  s  a 1  1 1  j 

J  ty.-.s 

’ 

Percent 

^erevM1; 

■  vrc*;-'- 

\ir  lor 

Of  Total 

ber 

0  f  1 0 1  a  1 

:<  •_  r 

■j  l  '  6 

Td'r1 

- 

0 . 0 

•ther 

crp. ■■  c-rat  i  o-  type 

-2 

49.1 

25 

:  - ' 

26 

3 ... .  5 

;  .  T  L  ■  J 

1 

1.3 

0.6 

1 

1 . 3 

1  1  -•  l  1 

•t 

integer  type 

0 

J .  0 

3.0 

4 

5 .  - 

Otner 

10 

17.5 

p  .V 

17.9 

0 

0.0 

rl.  -T 

j 

0 . 0 

0 

0.  1 

10 

12.7 

•.ner 

f  1  .  at.  i1  g-po int  type 

5 

14.0 

14 

8.5 

0 

0.0 

G 

2 

3.5 

5 

1.2 

0 

. .  G 

ther 

unconstrained  array 

U.O 

36 

21.3 

i 

1.3 

t'  el' 

constrained  array 

0 

0 . 3 

0 

0.0 

j 

11.4 

°ecor 

i  with  discri-  in  ;•  t 

J  ar 

ant  part 

1 

1.- 

1 

0 . 6 

0 

j ,  0 

variant  part 

1 

1 

0? 

v  ■ 

22.4 

0 

..0 

'.nt'  ‘ 

r6C'j 

5 

8.3 

17 

10.3 

20 

-  J  •  V 

::  r  i  v  i 

to  type 

i 

1.8 

1 

0.6 

0 

0.0 

7 

57 

103.1 

165 

100.0 

79 

-55.: 

■  .y  « -*  S 

53 

93.0 

15 

95.8 

55 

7 ; .  9 

.  P  *  / 

fj  < 

4 

7.0 

4 

2 . 4 

23 

7  9.1 

►;  r  •  , 

•  :  ‘  /j-t-u 

•,  .0 

2 

1 .  • 

0 

3.0 

3  ' 

100.0 

1 65 

1:0.. 

75 

loG.3 

•  h. 

1  ■  •  . 

3 

5.3 

3 

1.5 

23 

29.1 

.  •  - 

54 

34.7 

162 

98.2 

56 

70.0 

57 

10G. 

165 

100.0 

79 

1  '"\  '  ; 

istr  ib..'.iuft  for  indirg  and  •rot-jtype 
l_evc!r>  "j  a"']  9a  only) 


•  :  :  ■  .  :  .  pen)  ;  r.g 


»  ■  i  s  •  i ;  .  ■  •••>■!  n  .  j  i  n-.l  in 

•  .  '  ’  O  ',  1  i ;  ;  ;  n  .  *  ■  ■■  r-  r  -  ■  - ■: I  i  '  vs  t  em 

.1  '  ,  st  ’  .  i  Ml  ly  iii  t*w> 

!" t'  1  '  i  'i  '  d  na ml  I  i  no  . 

•  •  :  i  ’  .  •  rot  description 

'  r  ■  ,  i :  a  ,  >  . 1 1- 1  .  in  t  ho  1  i  f 

.  ’  1  :  o  ,  i  !'■  o  1  *  Ada  i  ,  t.  he  used 

:  *  •  ■  ■  .  '  ■  •  ■  i  •  ■  *  a  1 1 1  m  i  anyuu/ie . 

•  '  i  '  [■•*-  ■ :  ■  *  i.  1 1 t  to  vu  1  i date 

:  '  : .  ’  i  rj ■ :  ,  :r.to  Ada  ( tfii  t.  i  s ,  i  ‘ 

■  r  ■  .•  ;  I  JI  to  Ada  dt  e  :  "  tie 


•  The  full  power  of  the  Ada  language 
should  be  employed  in  defining  the  system, 
and  any  modifications  and/or  .optimiza¬ 
tions  performed  later. 

•  The  pro  iramming  support  environment 
is  very  r  portant.  A  non-val  idated 
compiler  can  be  a  Ip.  of  trouble  i*' 
features  likely  to  be  needed  are  not 
implemented.  The  sane  goes  for  support 
packages.  Validation  also  does  not 
guarantee  that  the  run-tine  system  pro¬ 
vides  the  necessary  support  for  a  GKS 
imi/1  ementat  ion . 

•  A  programming  support  environment  should 
include  a  sufficient  program  support 
library.  We  sorely  missed  having  a  math 
pack a  ;e  .  or  packages  for  low- level  !,o. 

A  validated  compiler  should  be  emrloved. 
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Binding 


Binding 

(Including  generically 
instantiated  types) 


‘.umber 

Percent 
of  Total 

Number 
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of  Total 
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0 

C.G 

Q 
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2 

2.2 

2 

O.S 

Other  -.r  constrained  array 

0 

0.0 

52 

21.7 

Other  constrained  array 

1 

1.1 

1 

0.4 

Record  with  discriminant 
Variant  part 

4 

4.4 

4 

1.7 

No  variant  part 

6 

6.6 

53 

24.2 

Other  record 

7 

7.7 

19 

7.9 

Private  type 

7 

7,7 

_ 7 _ 

2.9 

TOTALS 

91 

100.1 

240 

100. 0 

Types 

33 

91.2 

229 

95.4 

Subtypes 

S 

3.o 

3 

3.3 

Derived  types 

0 

0.0 

3 

1.3 

T';T/'L  S 

91 

100.0 

240 

100.0 

Predefined  types 

3 

3.3 

3 

1.3 

ser-defined  types 

38 

96.7 

237 

98.7 

totals 

91 

100.0 

240 

100.0 

TABLE  4.4-2 

Bata  Type  distribution  for  Binding 
(all  level s ) 


•  The  package  SYSTEM  and  Appendix  f 
should  be  .-«.i -lined  *or  support  for 
i';,j  ;.h  i  re-i.le:  endent  requi renents. 

■■  k  •  ow  I  edyemer.t  s 

This  paper  the  result  cf  work  performed 
jnde"  contract  number  F 4964Lr - <J 3 -C 00B j ,  sponsored 
bv  the  world  Wide  Military  Command  and  Control 
'systems  WWMCCS)  information  System  (WiS)  Joint 
Irograr  office  [.IW!,  and  guided  by  American 
National  Standards  >,'!tute  (ANSI)  < 3H34 .  the 
Language  Bindings  ard  Confom.ar  :e  Subcommittee 
of  the  Graphics  Technical  Committee.  The  auth  r 
al  ,o  wishes  to  ir.knowled  ;e  the  contributions  of 
’Seri  Cuthbc rt ,  Sam  riarbaugh,  and  Greg  Saunders. 
The  opinions  expressed  in  this  naper  are  not 
necessarily  tnose  of  WIN-  cm,  AN Si .  iso.  or 
-if’]  Cor;  or  it  i  ;>c . 
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Mil  IT  Alt  Y  (  (IMI'l  IKK  FAMILY  OPERATING  SYST 'KM:  AN  ADA  APPLICATION 


Krederick  K-  Wuehker 
Hi  A  (lovernment  Systems  Division 
Missile  and  Surface  Radar 
Moorestown.  Now  Jersev 


Sum  man 

The  Military  ( ’omputer  Family  Opel at  mg  System  -  M(  F'<  >K> 
Program  is  an  interesting  Ada'  application  effort  Not  only 
will  the  operating  system  lie  one  of  the  early  Ada  appltca- 
t  ion-,  hut  it  is  also  an  Ada  nperat  nut  svsteni  for  a  new  fa  till  I  \ 
ot  machine- and  is  designed  to  support  fielded,  real-time  Ada 
application-  programs  Finally,  the  operating  sy  stem  will  lie 
the  first  Ada  program  designed  to  he  a  formally  verified 
multilevel  secure  system.  This  amhitious  Imt  completely  do- 
ahle  program  will  certainly  stretch  the  state  of  the  tin  of 
ADA  programming.  it  not  actually  advance  tt  This  paper 
explores  some  of  the  Ada  issues  that  have  a  major  impact  on 
the  Mt  'Ft  IS  program. . 

Introduction 

In  August  19*2.  the  l  S  Army's  (  ommuntcations  and  Elec¬ 
tronic-  Command  '('KCt)Mi  at  Ft.  Monmouth  awarded  two 
compel  it  i  vo  cont  facts  tor  a  Military  Computer  Famtlv  Oper¬ 
ating  'Vstem  MLFOS  The  two  contractors  who  began  a 
competitive  definition  and  design  phase  were  RCA  and 
1  H\V  I  he  Mt  ’Ft  >S  con!  rad  required  t  he  deli  tut  ion  and  tup- 
level  design  of  extensions  to  the  Ada  Language  System  nec- 
essarv  to  support  the  const  ruction  of  A<  program-  targeted 
to  the  Ml  'F  machines  The  contract  also  required  the  defini¬ 
tion  and  top-level  design  of  a  famtlv  o  I  operating  systems  for 
the  Ml  f  machines  The  MCFOS  was  to  provide  functional 
capability  to  support  the  variety  of  applications  programs 
current  Iv  in  the  Army's  inventory  and  those  projected  for  toe 
hiture  I'he  Ml  Fi  IS  was  to  he  written  in  Ada  and.  of  course, 
to  support  applications  written  in  Ada  and  targeted  for  the 
Ml  f  machines  I  he  MCFIIS  f  tntly  is  to  support  the  com¬ 
plete  range  of  secure. y  requirements,  including  a  multilevel 
secure  operating  system  that  is  capable  of  passing  the  Class 
A  !  criteria  of  ihe  Doll  Computer  Security  Evaluation  Cen¬ 
ter  Those  criteria  require  machine  proofs  of  the  design  veri¬ 
fication  .d  well  as  code  compliance  assurance  Although 
proof  rules  lor  Ada  have  not  yet  been  published,  the  RCA 
team  of  RCA.  Interne-trie-.  and  Odyssey  Research  Associ¬ 
ates  ha-  been  examining  the  language  relation-hip  lor  seen 
rilv  and  lortnulating  procedural  usage  rules  in  insure  prnva- 
bllllv 


Yi  i  ■-  '  o-tn-n  a  irailttnark  a  !  la-  1  s  i  c.-.  ariin.*  lit  \.|,i  Imnt  IV.. 
coon  '  .  vll'n 


Brief  Description  of  the  Ml'K  Machines 

The  Military  Computer  Family  Program  began  in  1979, 
when  the  design  of  an  Instruction  Set  Architecture1  ISA  was 
undertaken  bv  Carnegie-Mellon  I'ntversuy  under  Armv 
sponsorship.  The  ISA  is  a  ,'12-hit  general-register  architec¬ 
ture  with  byte-addressable  memory  This  architecture, 
known  as  NFBLI.A  and  specified  as  MIL  STD  l>fi2B.  ha- 
the  following  features: 

•  Two  active  context  stacks 

•  Mapped  memory  with  access  protection 

•  Variable-length  instruction  with  variable  number  of  op¬ 
erands 

•  l  se  of  privileged  instructions  for  resource  control 

•  Vectored  interrupts  and  exceptions 

•  Virtual  1  O  with  1  ()  processors 

•  Explicit  addressing  of  all  instruction  operands 

•  Procedure-based  control  structure  with  a  local  register 
set  for  each  procedure 

The  Military  Computer  Faintly  consists  of  a  minicomputer,  a 
microcomputer,  and  a  single-hoard  microcomputer  I'he 
minicomputer  is  suited  for  large  systems,  such  as  command 
and  control,  large  phased  array  radar  systems,  and  intelli¬ 
gence  data  handling  systems.  The  microcomputer  is  in¬ 
tended  tor  smaller  embedded  applications  such  as  fire  con¬ 
trol  vehicle  control,  or  networked  communications.  The  sin¬ 
gle  hoard  microcomputer  is  a  compatible  machine  intended 
lor  use  in  embedded  weapons  control,  backpack  radio  con¬ 
trol.  and  intelligent  data  entry  systems. 

Table  1  shows  the  expected  perlormunce  lor  each  member  of 
the  family 

TABLE  1  MCE  CoMITTER  PERFORMANCE 

Single-Board 

Minicomputer  Microcomputer  Mu  recompute! 

SPEED  :l  MIPS  Ann  KIPS  Ann  KIPS 

ME  Ml  IRA  t  Mhvtes  i  A  A  Minn--  .-’An  Khvte- 

I’oWEK  lutiW  AnW  AW 

WHICH  !  (It  lb  in  lb  ii  7 A  It. 
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Synopsis  of  the  M(  F  Operating  System 

The  NH'K  operating  -\-teni  i-  to  he  a  familv  ot  compat ihle 
operating  system-  targeted  for  the  \1(  F  machines  This  fam¬ 
ily  i-  to  satisfy  the  Armv  V  needs  for  a  real-time  operating 
system  to  support  the  myriad  fielded  applications  that  will 
exist  on  the  NICK  machines  The  operating  system  is  to  he 
written  in  Ada  and  is  to  he  compatible  with  and  supportive  of 
applications  written  in  Ada  and  or  embedded  NKBE'EA  The 
operating  system  must  he  efficient  and  easily  understood.  It 
must  support  multiple  Ada  proprams  as  well  as  the  multi¬ 
task  mg  inherent  in  those  Ada  programs. 

Finally,  the  family  of  operating  systems  must  satisfy  the 
security  requirements  ot  systems  that  will  range  from  dedi* 
( . i ted  M-cure  through  multilevel  secure.  'Hie  multilevel  se¬ 
cure  operating  system  must  he  capable  of  verification  as  a 
<  lass  A-l  sv.-teni  as  q<  fried  by  the  <  ornputer  Security  Eval¬ 
uation  Criteria.”  dated  to  September  1 983  and  published  by 
the  Dolt  Computer  Security  Evaluation  (“enter 

An  operating  system  built  for  multilevel  secure  applications 
i"  faced  with  stringent  requirements  Mon-  important,  the 
Mt  Ft  IS  will  he  the  fn  -t  Ada  program  to  he  formally  verified. 

Ada  Issues  for  the  MCFOS 

Three  major  a  rear-  of ‘concern  he  investigated  n  insure 

that  the  operating  system  can  support  real-time  Avia  appli¬ 
cations  Tliese  are 

•  Control  of  the  machine  and  its  resources 

•  Real-time  performance 

•  Security 

Each  o!  these  areas  interacts  with  the  others  For  instance, 
control  of  the  machine  i-  not  only  required  to  insure  that 
multiple  VC  program.-  can  co-exist  within  the  machine,  hut 
! -  al-o  sublet  t  to  snme  very  -tnngent  rules  imposed  for  secu¬ 
rity.  -ecurqy  m  turn,  increase-  the  penalty  of  overhead  for 
prrlnnn.ifire  The  following  paragraphs  discuss  each  ofthese 
r  "f1h  ‘ 

Control  of  the  Machine  and  its  Resources 

\i  ;»*••  gin*,  -weir,  that  supports  Ada  programs  must  be 
■  ■qi.dde  1  <?  permitting  each  individual  program  s  Run  Time 
^upiM-rt  i  mr.irv  RSE1  to  -chedule  and  request  task  initia¬ 
te  ai  A i* hough  the  operating  system  has  no  knowledge  of  the 
-Cneduf mg  b'gu-  within  the  program  that  is.  for  example, 
the  i 'per-i* i ug  -v-tem  does  not  know  the  task  completion 
-tutu-  it  inu-i  honor  the  task  request  and  start  the  task  on 
the  rnai  inni- 

In  effei »  the  operating  system  takes  the  place  of  the  m;i- 
'  control  or  ’  rm<  l»  u  -  ’  portion  of  t lie  RSI.  for  the  applica¬ 
tion  program  I’he  operating  -v-tem  must  retain  control  oj 
the  machine  since  the  operating  -y-lem  controls  the  ■schedul¬ 
ing  "j  the  variou-  Ada  program-  that  it  support-  l  lierefore. 


when  an  Ada  program  i-  -u-p»-nd»*d.  the  ta-k  context  must 
he  preserved  and  provided  to  tin-  RSEof  th»-  suspended  pro 
gram.  As  an  a.dded  complexity.  Die  operating  ->-tern  is  ai.-o 
an  Ada  program  that  interface-  with  the  maleu-  USE 

In  a  multi  programmed  and  or  secure  environment,  the  oper¬ 
ating  system  must  maintain  control  of  the  memory  manage¬ 
ment.  It  must  honor  tin*  program's  request  for  data  object* 
and  insure  that  the  security  rules  for  those  data  object-*  are 
observed.  The  operating  system  must  al-o  honor  the  request, 
by  each  of  the  RSEs.  for  working  memory  space  The  Ada 
RSE  may  ask  for  space  in  small  increments  until  such  time 
as  the  maximum  memory  space  required  by  the  program  i> 
achieved.  The  RSE  retains  that  maximum  amount  until  the 
program  completes  or  is  terminated.  For  the  operating  sys¬ 
tem.  this  creates  the  problem  of  providing  small  increments 
and  having  the  memory  returned  in  a  large  block.  The 
memory  management  for  MCFOS  must  run  mapped  because 
a  secure  operating  system  requires  paged  or  segmented 
mapped  memory  to  assure  protection  without  an  extraordi¬ 
narily  complex  logic  and  a  high  overhead  for  memory  man¬ 
agement 

The  machine-dependent  portion  of  the  RSE.  referred  to  as 
the  nucleus  RSE.  will  actually  control  the  target  machine. 
Many  nucleus  RSEs  will  exist  hut  ideally  the  machine-inde¬ 
pendent  portion  of  the  RSE  should  be  identical  for  all  Ada 
programs.  Two  sets  of  interfaces  are  involved. 

The  first  set.  to  insure  portability  at  the  source  level,  con¬ 
sist.-  of  user  interfaces.  The  RSE  should  conform  to  the  com¬ 
mon  Ada  Programming  Support  Environment  'APSE1  inter¬ 
face  set  as  defined  by  the  Kerne)  APSE  interface  team  As 
seen  now.  there  will  have  to  he  "RSE-hke”  extensions  to  that 
interface  definition  for  various  environments  These  exten¬ 
sions  must  he  built  as  a  set  that  does  not  impact  the  common 
-et  and  can  he  added  to  the  machine-independent  portion  of 
RSI.  as  needed  for  the  implementation.  The  MCFt  )S  requires 
a  set  for  such  function.-  as  interprocess  communications,  de¬ 
vice  control,  and  process  control  These  are  Ada  packages 
that  will  he  added  to  the  common  M’SE  interface  set. 

The  second  set  of  interfaces  is  much  more  difficult  'Hus  -ot 
involves  the  interfaces  between  the  machine-independent 
RSE  and  the  nucleus  RSE  A  common  interface  should  he 
designed  to  simplify  portability  to  various  target  machines 
The  current  set  of  compilers  interfaces  with  the  host  ma¬ 
chine-  operating  system,  ie.  TeleSoft  and  Soflech  inter¬ 
face  with  VAX  VMS  and  ROEM  Data  (Jeneial  interfaces 
with  AOS'  Eventually  a  common  interface  should  lie  de¬ 
fined  between  the  machine-independent  portion  and  the  RSI 
nucleus  Figure  1  depicts  the  various  interfaces  necessary  to 
go  from  Ada  constructs  to  execution 

Keal*Time  Performance 

The  MCFMS  )-  to  1  »e  a  reaEltrue  operating  system,  and  effi¬ 
ciency  i<  therefore  of  paramount  importance  The  RSE  and 
it-  relationship  with  the  Ada  programs  must  he  investigated 
and  understand  The  reader  mu-t  remember  that  the  Ada 
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Figure  1.  Ada  Construct-ta-execution  Flow. 

programs,  operating  under  the  MCFOS,  communicate 
through  the  machine-independent  portion  of  their  RSLs  to 
an  operating  system.  That  operating  system  is  an  Ada  pro¬ 
gram  that  must  verify  and  interpret  the  request  and  trans¬ 
mit  the  desired  action  to  the  n  cleus  RSL  for  execution.  That 
Ada  program,  called  MCFOS.  must  control  the  application 
Ada  programs  its  supports. 

The  NEBULA  architecture,  is  an  excellent  (though  not  per¬ 
fect'  instruction  set  architecture  for  the  implementation  of 
Ada.  A  measure  of  the  efficiency  may  be  taken  from  the 
number  of  instructions  that  must  he  executed  to  suppoi  an 
Ada  request  such  as  task  execution,  task  termination, 
memory  request,  etc.  To  do  this  an  Ada  RSL  has  been  con¬ 
structed  and  instrumented  to  provide  statistics  related  to  the 
execution  of  Ada  programs  on  an  MCF  computer.  The  statis¬ 
tics  consist  of  instruction  counts  and  response  times  for  each 
of  the  requested  Ada  operations.  Table  II  shows  sample  va¬ 
lues  collected  for  a  multiple  Ada  program  implementation. 

TABLE  II  ADA  PERFORMANCE  ESTIMATE 

Average 

Process  Instruction  Count 


Program  Initiation  99 

Task  Initiation  185 

Entry  Call  27 

Accept  36 

Rendezvous  Initiation  28 

Rendezvous  Completion  54 

Task  Scheduling  108 

Task  Termination  22 


Although  it  is  expected  that  there  will  he  some  improvement 
in  these  figures,  analysis  shows  that  an  nrder-of-magnitude 
improvement  will  not  occur  These  types  of  statistics  will 
definitely  influence  various  factors  considered  in  the  an  hi- 
tecture  of  an  Ada  program 

Security 

Since  the  Mi  H  >S  h '.i  i»- i  i.i'~  4  i  multilevel  secure  oper¬ 
ating  s\stem  the  fe-  ge  s-rrnallv  verified  and  ma¬ 
chine  prn\ »-n  I  l  ,  ,•  ......  .....ua  ih,.n  he  shown 


to  satisfy  the  security  policy  This  "proof"  is  a  manual  proc¬ 
ess  that  relies  on  proof  rules  that  reflect  the  semantics  of  the 
data  structures  and  control  constructs  of  the  high-order  lan¬ 
guage  used.  Proof  rules  for  Ada  have  not  yet  heen  published, 
hut  the  work  done  by  Odyssey  Research  Associates  shows 
that  Ada  is  verifiable  if  its  usage  is  restricted.  Such  restric¬ 
tions  do  not  violate  the  ''thou  shall  not  subset''  command¬ 
ment.  They  represent  a  self-imposed  discipline  with  the 
same  status  as  an  in-house  program  development 
methodology. 

The  restrictions  chosen  have  been  assembled  from  a  variety 
of  sources,  and  although  they  are  not  optimum,  they  do  pro¬ 
vide  a  baseline.  If  during  implementation  it  is  found  that  the 
restrictions  are  too  stringent,  they  will  be  reviewed 

On  the  basts  of  the  study  conducted  by  Odyssey,  a  set  of  nine 
restrictions  will  be  used.  It  is  felt  that  Ada  programs  written 
using  the  discipline  listed  here  can  be  proved  correct. 

1.  No  aliasing;  that  is  — 

•  do  not  use  a  global  variable  as  an  actual  parameter 
in  a  subprogram  or  entry  call 

•  In  calls,  distinct  actuals  should  be  used  for  distinct 
formals  of  inode  out  or  in  out.  and  no  such  actuals 
should  be  used  within  an  expression  bound  to  a  for¬ 
mal  in  parameter. 

2.  No  variant  records. 

’>  No  generics  with  subprogram  parameters. 

4  Documentation  of  exception  propagation  and  exception 
handling;  no  handling  of  the  task  failure  execution 

5.  No  shared  variables  between  tasks,  i.e..  ail  tasks  com¬ 
municate  explicitly  through  entry  calls  and  accept 
statements. 

6.  No  access  variables  as  formal  parameters  to  entries 

7.  No  dynamic  task  creation  using  task  types  and  task 
access  variables. 

8.  No  delay  statements  or  condit  nal  entry  calls  or  timed 
entry  calls. 

9  No  real  types. 

‘  urrent  Status 

The  MCFOS  program  has  completed  the  <  incept  Definition 
Phase,  with  the  top-level  design.  The  second  phase,  about  to 
start,  will  he  the  Interim  Operating  Kys  m  phas'C  Thi~ 
phase  will  involve  bunding  an  interim  secure  operating  sys¬ 
tem  that  will  b-  a  subset  of  the  MCFOS.  targeted  for  the 
MCF  Advanced  Development  Model  machines  Also  during 
this  period  the  formal  specification  and  secure  verification  1  i 
ihe  multilevel  secure  operating  system  w  ill  be  accomplished 
and  the  detailed  design  completed 

During  this  period  the  RSLs  for  the  MCF  implementat’oii 
will  he  completed  and  the  real  performance  ol  a  full  -c.de 
Ada  implementation  can  he  assessed 
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Abatract 

^  As  part  of  the  Military  Computer  Family 
Operating  System  (MCFOS)  project,  extensions  to  the 
Ada  Language  System  (ALS)  are  being  constructed 
which  allow  software  for  the  MCF  computers  to  be 
developed  and  tested  in  a  host/target  environment. 
These  extensions  are  collectively  known  as  the  ALSE. 
ALS  facilities  are  used  for  editing,  compiling,  linking, 
and  exporting  Ada  programs,  while  ALSE  facilities  are 
used  to  download  the  software  into  a  connected  MCF 
computer  and  execute  the  software  on  the  MCF,  thus 
providing  state-of-the-art  high  level  debugging  and 
performance  monitoring  facilities  in  an  embedded  target 
environment.  This  paper  describes  the  components  of 
the  ALSE  from  a  user  viewpoint,  concentrating  on  how 
an  applications  programmer  would  use  MCFOS  and  the 
Extended  Ada  Language  System  to  develop  software. 

ry 


Introduction 

In  August  1982,  TRW  was  awarded  a  contract  by 
the  U.S.  Army  Communications-Electronics  Command 
(CECOM)  to  develop  requirements  and  top-level  design 
of  two  operating  systems  for  the  Military  Computer 
Family  (MCF)  computers.  Both  operating  systems  were 
to  be  written  in  Ada  and  were  to  be  designed  to  support 
real-time  Ada  applications.  The  Dedicated  Secure 
Operating  System  was  to  be  run  in  either  a  dedicated  or 
system  high  mode,  and  was  to  be  optimized  for 
efficiency,  while  the  Multilevel  Secure  Operating  System 
was  to  be  designed  to  support  multilevel  secure 
applications. 

As  part  of  this  Military  Computer  Family 
Operating  System  (MCFOS)  contract,  extensions  to  the 
Army  Ada  Language  System  (ALS)  were  to  be  designed 
which  would  allow  the  user  to  develop  and  test  software 
for  the  MCF  computers  using  the  facilities  of  the  ALS. 
Together,  the  Extended  Ada  Language  System  and 
MCFOS  provide  support  for  all  phases  of  software 
development:  design,  coding,  debugging,  optimization, 
testing,  and  deployment. 


Ada  and  MCFOS 

The  MCFOS  project  uses  Ada  in  several  different 
ways.  First,  MCFOS  itself  is  written  in  Ada.  Second, 
MCFOS  supports  Ada  applications.  An  applications 
program  can  interface  with  MCFOS  in  three  different 
ways:  through  Ada  language  semantics  such  as  tasking 
or  exception  handling,  through  Ada  standard  packages 
such  as  those  for  input/output,  and  through  MCFOS 
packages  which  provide  capabilities  beyond  those  which 
are  part  of  Ada.  Therefore,  MCFOS  serves  as  a 
replacement  for  and  extension  of  the  runtime  support 
library  provided  with  the  Ada  compiler.  It  should  be 
noted  that  the  real-time  and  security  requirements 
imposed  on  MCFOS  require  that  much  of  the  ALS 
runtime  support  library  be  replaced. 

The  Ada  Language  System  Extensions 

The  Extended  Ada  Language  System  consists  of 
the  Army’s  Ada  Language  System  (ALS)  augmented  by 
the  Ada  Language  System  Extensions  (ALSE). 
Together,  the  ALS  and  ALSE  provide  facilities  for 
developing  Ada  programs  targeted  to  an  MCF 
computer.  To  do  this,  a  host/target  configuration  is 
used,  in  which  the  host  computer  is  a  VAX  11/780  and 
the  target  computer  is  any  one  of  the  three  computers 
in  the  Military  Computer  Family  -  an  AN/UYK-41, 
AN/UYK-49,  or  the  Single  Module  Computer.  As 
many  as  four  MCF  computers  can  be  connected  to  the 
VAX  via  a  hardware  link. 

The  ALSE  has  three  components:  target 
dependent  tools,  software  development  monitors  and  a 
VAX/MCF  link.  The  target  dependent  tools  consist  of 
the  MCF /Ada  Symbolic  Debugger,  MCF/Ada  Timing 
Analyzer,  MCF/Ada  Frequency  Analyzer,  and  ALSE 
Profile  Display  Tool.  There  are  two  software 
development  monitors:  a  Single  User  Monitor  to  support 
a  single  application  executing  on  a  bare  MCF  machine, 
and  a  Virtual  Machine  Monitor  to  provide  a  multiuser 
capability  for  Ada  program  development  in  the 
host/target  environment.  The  VAX/MCF  link  consists 
of  a  hardware  connection  between  the  VAX  and  the 
MCF,  software  to  support  the  link,  and  the  VAX/MCF 
leader,  which  downloads  MCFOS/applications  software 
from  the  VAX  into  the  MCF. 
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Figure  1  shows  the  Extended  Ada  Language 
System,  with  shading  indicating  the  ALSE  components 
to  be  developed  as  part  of  the  MCFOS  project. 

Software  Development  Monitors. 

The  ALSE  has  two  types  of  Software 
Development  Monitors,  a  Single  User  Monitor  (SUM) 
and  a  Virtual  Machine  Monitor  (VMM).  Both  monitors 
provide  a  bare  machine  interface  to  Ada  programs 
executing  on  an  MCF  computer,  support  the  other 
ALSE  took  being  used  for  Ada  program  development 
on  the  MCF,  and  provide  for  simulation  of  unavailable 
peripheral  devices.  The  Virtual  Machine  Monitor  also 
provides  a  multiuser  capability  for  Ada  program 
development  in  a  host/target  environment.  The 
monitors  execute  primarily  on  the  MCF,  with  the 
peripheral  simulation  function  executing  on  the  VAX. 

All  software  developed  using  the  Extended  Ada 
Language  System  will  run  under  control  of  one  of  the 
monitors.  The  VMM  provides  the  capability  of 
simultaneously  running  one  or  more  Ada  applications 
for  debugging  or  testing  purposes.  The  SUM  provides  a 
more  efficient  capability  for  debugging  or  testing  a 
single  Ada  application. 

Developing  Software  With  MCFOS  and 
ALSE. 

In  this  section,  we  illustrate  how  applications 
software  would  be  developed  and  tested  using  the 
facilities  provided  by  MCFOS  and  the  Extended  Ada 
Language  System.  It  is  assumed  that  the  applications 
software  is  designed  to  run  under  MCFOS. 

First,  already  existing  facilities  of  the  Ada 
Language  System  are  used  to  develop  the  software  on 
the  VAX  11/780,  as  shown  in  Figures  2  and  3.  These 
facilities  include  the  ALS  Editor,  the  Ada  compiler  with 
MCF  code  generator,  the  MCF  Linker,  and  the  MCF 
Exporter.  The  MCFOS  SYSGEN  function  then 
combines  the  exported  load  module  with  MCFOS  to 
produce  a  tactical  system  suitable  for  loading  into  the 
MCF  computer.  Note  that  this  MCFOS  function 
executes  on  the  VAX  rather  than  on  the  MCF.  Figure 
4  depicts  the  process  of  building  a  tactical  system. 

The  output  from  SYSGEN  is  now  ready  to  be 
downloaded  across  the  hardware  link  into  the  MCF 
computer.  This  is  accomplished  by  the  VAX/MCF 
I/iader.  Three  types  of  loads  across  the  link  can  occur. 
First,  the  Software  Development  Monitors  can  be 
loaded  onto  a  bare  machine.  Later,  applications 
software  that  is  to  run  under  control  of  a  Software 
Development  Monitor  can  be  loaded  onto  the  MCF. 
Finally,  a  system  ready  to  be  deployed  can  be  loaded 
through  the  MCF  directly  onto  an  MCF  peripheral, 


from  which  it  can  be  loaded  onto  an  MCF  in  the  fi*  Id 
These  operations  are  depicted  in  Figure*  V  ft  and  7 

The  VAX/MCF"  leader  also  provide*  overall 
control  (on  the  VAX  side)  between  element*  of  the 
ALSE  and  responds  to  user  commands  That  is  other 
ALSE  tools  such  as  the  MCF/Ada  Symbolic  Debugger 
the  MCF/Ada  Timing  Analyzer,  and  the  MCF’/ Via 
Frequency  Analyzer  are  invoked  via  loader 
subcommands. 

After  the  MCFOS/applications  load  module  lias 
been  loaded  it  is  ready  to  be  executed  It  can  either  he 
executed  directly,  with  or  without  timing  and  frequency 
analysis,  or  it  can  be  executed  under  control  of  the 
MCF/Ada  Symbolic  Debugger.  This  tool  is  functionally 
identical  to  the  ALS  VAX/VMS  Symbolic  Debugger  It 
allows  controlled,  incremental  execution  of  the  target 
program,  symbolic  display  of  the  state  of  the  program, 
symbolic  display  of  program  entities,  and  symbolic 
modification  of  program  variables.  Figure  8  shows  the 
operation  of  the  Debugger  within  the  ALSE. 

If  the  software  is  to  be  executed  directly,  a 
different  loader  subcommand  is  specified.  Parameters 
to  this  subcommand  indicate  if  timing  analysis  and/or 
frequency  analysis  are  to  be  performed.  The  MCF/Ada 
Timing  Analyzer  is  functionally  identical  to  the  ALS 
VAX/VMS  Timing  Analyzer.  It  monitors  the  execution 
time  characteristics  of  Ada  programs  executing  on  an 
MCF  computer,  by  counting  how  often  each  block  in  an 
Ada  program  is  in  control  at  the  end  of  a  specified  time 
interval.  Likewise,  the  MCF/Ada  Frequency  Analyzer 
is  functionally  identical  to  the  corresponding  ALS 
VAX /VAIS  tool.  It  monitors  the  execution  frequency 
characteristics  of  Ada  programs  executing  on  an  MCF 
computer,  by  counting  how  many  times  each  block  in 
an  Ada  program  has  beeD  executed.  In  both  cases,  the 
collected  timing  and  frequency  data  are  stored  in  an 
ALS  file  (on  the  VAX  system)  whose  name  is  specified 
on  the  execution  command.  This  data  can  then  be 
displayed  by  the  ALSE  Profile  Display  Tool,  which 
executes  entirely  on  the  VAX  and  produces  histograms 
which  measure  how  often  or  how  many  times  a 
particular  subprogram  or  block  was  executed.  Like  the 
other  ALSE  target  dependent  took,  it  is  functionally 
identical  to  its  corresponding  VAX/VMS  tool.  Figures 
9  and  10  show  the  operation  of  the  Timing  and 
Frequency  Analyzers  and  the  Profile  Display  Tool, 
respectively. 

Summary 

Together  with  MCFOS,  the  Extended  Ada 
Language  System  provides  support  for  all  phases  of 
software  development,  from  design  through  deployment. 
It  allows  a  programmer  to  develop,  debug,  and  test  Ada 
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ABSTRACT 

The  authors  demonstrate  the  feasibility  of 
eon  vert  ing  the  Unpack  routines  for  analyzing 
and  solving  s  vs  terns  of  linear  equations  from 
FORTRAN  to  Ada.  This  is  clone  with  minimal  al¬ 
teration  of  the  original  program  structure,  thus 
requiring  very  little  re-orientation  by  current 
users  of  UNPACK. 


INTRODUCTION 

A  number  of  questions  have  been  raised  as  to 
whether  Ada  is  an  appropriate  language  for  gene¬ 
ral  scientific  eomputat ions.  In  order  for  Ada 
to  he  so  used,  it  is  required  that  a  number  of 
software  packages  now  used  in  FORTRAN  he  adaptable 
to  Ada.  One  software  package  that  is  widely  used 
and  highly  developed  in  FORTRAN  is  UNPACK. 

UNPACK  is  a  collection  of  FORTRAN  subrou¬ 
tines  which  analvzes  and  solves  various  systems 
of  simultaneous  linear  algebraic  equations.  It 
is  the  aim  of  this  paper  to  demonstrate  the  fea¬ 
sibility  of  recoding  the  UNPACK  routines  to  the 
Ada  language. 

It  has  been  pointed  out  (see  Morris  (2)) 
that  a  deficiency  in  the  Ada  language  is  its 
failure  to  include  internal  representat ion  of 
arravs.  The  FORTRAN  standard  requires  that 
arrays  bo  stored  in  column  major  form,  that  is, 
columns  are  stored  together  one  after  the  other. 
This  standard  along  with  the  absence  of  strong 
tvping  allows  the  programmer  to  access  the  ele¬ 
ments  of  a  matrix  as  if  it  were  a  vector  and  al- 
wavs  set  the  right  element.  It  is  this  standard 


among  others,  that  has  permitted  the  development 
of  tin*  UNPACK  routines.  Tins  paper  demonstrates 
an  approach  at  recoding  the  UNPACK  routines  that 
requires  minimum  re-orientation  hv  current  UNPACK 
use  rs . 


MJTHODS  _OJ  CONVERSION 

There  are  three  approaches  to  the  recoding  of 
the  UNPACK  routines  which  seem  obvious  and  strai¬ 
ghtforward.  The  first  approach  is  to  merelv  insert 
the  appropriate  codes  for  the  various  HI. AS  routines 
in  the  various  places  where  the  subroutine  calls 
are  made.  This  would  reduce  the  work  required  in 
performing  the  conversion.  The  effect  of  this  in¬ 
sertion  on  execution  time  should  he  minimal  since 
no  extra  code  is  being  executed.  In  fact,  the 
overhead  of  the  subroutine  call  is  saved.  However, 
it  would  significantly  increase  the  space  require¬ 
ments  for  the  program  code.  It  would  also  destroy 
the  modularity  and  the  readihilitv  of  the  routines. 

The  second  approach  is  to  process  the  matrices 
and  vectors  prior  to  the  Bl.AS  subroutine  call  and 
postprocess  them  after  the  151, AS  subroutine  call. 

The  preprocessor  would  remove  the  appropriate  por¬ 
tion  of  the  column  of  the  matrix  or  the  appropriate 
portion  of  the  vector.  This  approach  is  placed 
hack  in  its  place  in  the  matrix  or  vector.  This 
approach  maintains  the  readihilitv  and  modularity 
of  tlie  program.  The  increase  in  space  require¬ 
ments  is  minimal  in  that  onlv  four  short  routines 
are  needed  in  addition  to  the  usual  ones.  The 
increase  in  time  requirements  is  also  minimal  since 
the  only  thing  these  routines  do  is  transfer  seve¬ 
ral  data  items  hark  and  forth. 

The  third  approach  is  to  define  the  matrix  to 
he  an  array  of  vectors.  After  the  matrix  to  he 
used  is  proper] v  defined  the  appropriate  vector  is 
sent  to  the  BT.AS  subroutine.  In  order  to  use  this 
technique  the  vectors  to  be  transferred  must  be 
the  columns  of  the  matrix.  This  may  require  a  rou¬ 
tine  to  compute  the  transpose  of  the  matrix  before 
proceeding.  Therefore,  the  increase  in  space  re¬ 
quirements  and  in  execution  time  should  he  minimal. 
Tlie  Ada  concent  of  slices  mav  prove  useful  in  this 
approach . 
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I'!!!  IMPLEMENTATION 

:'hc  Urst  alternative  was  dismissed  as  being 
the  least  attractive  alternative.  The  second  al¬ 
ternative  inneared  to  be  the  easiest  to  implement 
quick lv,  am!  so  was  considered  first.  The  third 
alternative  is  presently  being  pursued. 

In  order  to  implement  the  second  alternatives, 

1  \  NTL-\CK.  and  REAS  routines  for  a  general  system  were 
ended  in  Ada.  The  changes  made  in  the  programs 
were  of  two  tvpes.  The  first  type  of  changes  sim- 
p 1 v  involved  the  use  of  structured  programming 
technique  making  use  of  control  structures  not 
available  in  FORTRAN.  The  second  type  of  change 
involved  writing  four  new  routines  call  CONVRTM, 
HFCONYRTM,  CONVRTV,  and  RKCONVRTV .  The  first  two 
routines  work  on  matrices.  CONVRTM  takes  a  given 
nor t ion  of  a  column  from  a  matrix  and  stores  it  in 
a  vector.  R1T0NVRTM  takes  a  portion  of  a  column 
from  -i  vector  and  replaces  it  in  a  matrix.  The 
other  two  routines  do  similar  things  for  a  vector. 

Hie  routines  are  used  in  conjunction  with  the  BLAS 
routines  as  follows: 

The  FORTRAN  statement  CAM.  SAXPY (N-K, T, A (K+ 1  , K) , 
l,B(K+l), l) 

is  replaced  hv  the  Ada  sequence  : 

CONVRTM fN-K , K+ 1 ,K, A,X, 1) ; 

CONVRTV  (N-K  , K+ i , B , Y) ; 

R ! ■  ( :ONV RTM fN-K, K+l  ,K, A,X , 1 ) ; 

RfXONVRTV(N-K,K+l,B,Y)  ; 

The  structure  of  the  Ada  package  that  imple¬ 
mented  the  UNPACK  routines  is  listed  below.  The 
package  bodies  were  coded  under  ADAED,  version 
1<S.  Because  of  the  nature  of  ADAED,  extensive 
testing  is  not  possible.  A  simple  system  of  five 
equations  in  five  unknowns  took  30  minutes  of  CPT 
time  to  compile  and  execute. 

PAT  KAO  F  UNPACK  TS 

FT  NTT  I ON  I S AMAX (N : T  NDFX ; X : VKCTOR )  RETURN  INDEX; 
FUNCTION  SASi'M  (N  :  TNI) EX  ;  X  :  VKCTOR)  RETURN  REA1. ; 

FUNCTION  SHOT  fN: INDEX; X,Y: VECTOR)  RETURN  REAL; 
PROCEDURE  SAXPY (N: INDEX ;S:REAL;X: IN  OUT  VECTOR); 
PROCEDURE  SSCAUN:  INDEX  ;S:REAL;X:  IN  OUT  VECTOR): 

P  R0( :  EDI  'RE  ( :0NV  RTM  (N ,  K ,  I. :  I ND  EX  ;  A :  MATR  T  X  ;  V :  OUT  V  ECTOR 
: INC: INDEX) ; 

PROCEDURE  RECONVRTM (N,K , L: INDEX ; ArOUT  MATRIX; V: 
VECTOR; INC: INDEX) ; 

PROCEDURE  CONVRTV ( N,K: TNDEX; B: VECTOR ;V: OUT  VECTOR) ; 
PROCEDURE.  RF. CONVRTV (N,  K:  INDEX ;  B: OUT  VECTOR; V: VECTOR)  ; 
PROCEDURE  SO ESI. (A: TN  OUT  MATRIX ;LDA,N: INDEX; TPVT: 

IN  OUT  INTVEC; B: IN  OUT  VECTOR ; JOB : TNDEX) ; 
PROCEDURKSCEFA (A:  TN  OUT  MATRIX; EDA, N: TNDEX; TPVT: 

IN  OUT  INTVEC; TNFO: OUT  INDEX); 

END  UNPACK; 


limitations  of  ADAED,  especial lv  its  execution 
speed,  any  real  testing  must  await  a  compiler. 
Nevertheless,  it  is  clear  that  the  routines  can  be 
fairly  easily  recoded  in  Ada.  The  costs  incurred 
in  this  recoding  cannot  be  determined  at  this  time. 
Other  approaches  may  also  be  available  besides  the 
ones  indicated  above.  The  third  alternative  mnv 
be  the  best  of  the  three.  There  are  indeed  un¬ 
answered  questions,  but  we  must  conclude  that  it  is 
feasible  to  salvage  at  least  a  portion  of  a  "quar¬ 
ter  centurv  accumulation  of  logic  and  code." 
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CONCLUSIONS 


While  it  may  not  be  possible  to  retain  all  of 
the  character  ist  irs  of  the  UNPACK  routines  in  a 
conversion  to  Ada,  it  has  been  demonstrated  that 
such  a  conversion  is  possible.  Because  of  the 


103 


ADA  ^  ASK  1 NC.  IN  NUMERICAL  ANALYSIS 


<j> 

CM 

CO 

O 

O 

Q. 

I 

D 

< 


John  J.  Buoni* 


Mathematical  and  Computer  Sciences 
Youngstown  State  I'nivrrsitv 
Youngs  town  ,  Ohio  44ar>r> 


Abstract 

"  “Recently  the  interests  in  the  use  of  iter¬ 
ative  methods  for  the  solution  of  Partial  Defer¬ 
ential  Equations  has  been  revived.  Also,  the 
advent  of  multiprocessor  computer  systems/*'vi  1  1 
lead  many  to  reformulate  much  of  the  existing 
theory  of  numerical  analysis.  It  is  felt  that 
Ada's  portability  and  rich  resources  will  play 
an  important  role  in  this  rekindled  interest. 

The  purpose  of  this  paper  is  to  discuss  three 
different  implementations  of  a  classical  iter¬ 
ative  methods  for  the  solution  of  a  numerical 
problem  using  several  Ada  tasks. N 


I .  Introduction . 


In  this  paper  we  shall  comment  on  some 
methods  for  solving  linear  systems  of  the  form 
Au=b  (1) 


where  A  is  a  given  real  NxN  matrix  and  b  is  a 
given  real  column  vector  of  order  N. 

We  shall  describe  three  different  implement¬ 
ations  of  an  elementary  iterative  method  for  sol¬ 
ving  (1)  which  uses  Ada  tasking.  Such  methods 
appear  to  be  ideally  suited  fo:  problems  involv¬ 
ing  large  sparse  matrices. 

In  order  to  illustrate  our  discussion  we 
shall  consider  the  following  model  problem:  let 
C(x,v)  and  g(x,y)  be  continuous  functions  defined 
in  the  interior,  I,  and  on  the  boundary,  B  of 
the  unit  square  0<x^’  ,0<y<l .  We  seek  a  function 
u(x,y)  continuous  in  I+B,  which  is  twice  contin¬ 
uously  differentiable  in  l  and  which  satisfies 
Frisson's  equation, 

i  2  9 

— 9  +  a - +  — 2  G(xfy)  (2) 

ax*"  ax3y  dv 


where  a  is  a  constant. 

On  the  boundary,  u(x,y)  satisfies  the 
cond i t ion 

u(x,v)=g(x,v) . 

If  0(x,v)=0  and  a=0,  then  (2)  reduces  to 
Laplace's  equation 


ax  av 


(3) 

(4) 


We  shall  be  concerned  with  the  linear  system 
arising  from  the  numerical  solution  of  the  model 


*  Dedicated  to  Bernard  J.  Yozwiak  on  the  occasion 
of  his  sixtvfifth  birthday,  July  5,  1984. 


problem  using  i  five-point  diMerence  i-quat  ion. 

We  super  impost-  a  mesh  of  horizontal  am!  vertical 
lines  over  the  region  with  t  Uniterm  s; a»  ing, 
h  ”  M“  I  ,  tor  sonu  integer  M.  We  s*  »-k  to  determine 
approximate  values  of  mx.vt  it  the  mesh  pejnts 
and  use  tin  a;-prox  im.-.t  i-m- 

-  - ,  f  1 1  (  x4  h  ,  v  i  +  ii  (  x  —  h  ,  v  i  -  ’  u  (  x  ,  1  !  1  '  , 

'i  (  S  t 

-  9  ( u  (  V  ,  v +»: )  -*-u  (  *  1 1  -  1 1  (  >. ,  \  >  1  1,  '. 

.*v  “ 

Replacing  the  partial  derivatives  i  n  ( .' )  ami 
multiplying  bv  -h  we  obtain  the  d i t t » ren« e  equa- 
t  i  on 

4u  (x,  v  )-it  (  x+h ,  v  )-u  ( x-hi ,  v  )  -u  {  x  ,  v+h  )  -  u(  x ,  v-h ) 

=  - h  ( I  ( x , v )  (M 

4u  (x  ,  v  )  -u  (  x ,  v+h )-u  ( x ,  v-h ) -  ti  (x+h ,  v  )  -u (  x-h ,  v  ) 

=-h  ( : ( x , v ) 

To  bo  specific,  if  C,(x,v)  =  0  and  if  h=lM, 
we  have  the  situation  shown  in  Figure  1.  We  seek 
approximate  values  of  u^=u(xj,v^)  for  i  =  1  ...a. 


The  values  of  u  at  the  points  labeled  5,b,. 
are  determined  bv  (3).  Thus  we  have  u,=gr, 

3  > 


etc.  From  (A)  we  obtain 


4V‘2 


iu2-un‘u4-urui5=0 

4uru4-'vu?-ur° 

4VU12_U10~W0- 


(7) 


1 1 .  Vector  Product. 

Let  us  consider  the  following  example  for  a 
moment  and  recall  the  multiplication  of  a  matrix 
A(i,j)  by  a  vector  u(j)  where  i=l...n,]=l...m 
and  perform  the  matrix  operation  Axu.  This  ma¬ 
trix  operation  is  performed  by  multiplying  each 
row  of  the  matrix  A  by  the  vector  u.  It  is  part 
of  the  folklore  in  mathematics  that  these  opera¬ 
tions  can  be  performed  in  parallel. 

A  partial  Ada  solution  is  the  following  code 
presented  here  only  for  a  proper  historical  ap¬ 
proach  . 

Example  1 

type  Matrix_Row  is  arrav  ( integer  range  *''•) 
of  float; 

type  Pointer  is  access  MatrixRi.w 
task  type  Vec tor_Produc t  is 

entry  Receive_Value(P  ;out  float); 
entry  Send  Value  (Vector  1 , Vec tor 2 : 
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in  Matrix  Row); 
end  Vector  Product; 

Task  body  Vector .Product  is 
Product  :  float; 

Vector  Pointerl  :  Pointer; 

Vector  Pointer2  :  Pointer; 
begin 

accept  Send_ Value (Vec tori ,Vec tor2 : 
in  Matrix  Row)  do 

Vec tor_Po inter  1  :=  new  Matrix__Row' 

(Vec tor  1 ) ; 

Vector  J5ointer2  :-new  Matrix  Row' 

(Vec tor 2) ; 
end  St?nd  _Va  1  uos ; 

Produc t : -0. 0; 

for  i  in  Vec tori  all* range 
loop 

Product  :®Product+(Vector  1  (i  )*Vector2  (i ) ): 
end  loop; 

accept  Receive  Value (P  :  out  float)  do 
P :«Produc  t ; 
end  Receive  Value; 
end  Vec tor_produc t ; 

Although  such  an  algorithm  is  interesting, 
for  large  matrix  problems  many  of  the  entries  are 
zero  (sparse)  and  the  non- zero  entries  are  banded 
along  the  diagonal.  This  motivated  Karush 
et  all®  to  derive  a  procedure  for  matrix  multi¬ 
plication  by  diagonals  suitable  to  certain  paral¬ 
lel  processors.  See  also  Jordan?  and  for  other 
related  work  Kowalik  et  a  1 1  ^ . 


III.  Synchronous  Approach. 

The  prospect  of  using  a  mul t iprocessing 
computer  system  to  solve  linear  problems  is 
quite  appealing  and  appears  to  date  back  to 
Rosenfeld  et  all^.  If  one  considers  Figure  1, 
one  obtains  a  grid  point  stencil  of  the  follow¬ 
ing  form? 


Figure  (a). 

If  we  generate  as  many  tasks  as  there  are  interior 
grid  points,  each  interior  point  and  its  associ¬ 
ated  stencil  of  components  could  be  assigned  one 
Ada  task  i.o.  isl,...,A,  as  in  Figure  1.  The 
boundary  nodes  are  not  assigned  any  tasks,  but 
instead  their  values  are  stored  in  the  tasks  that 
need  them,  see  Figure  1.  The  data  rendezvous 
between  tasks  is  performed  using  other  coordi¬ 
nator  tasks.  Before  considering  a  draft  of  the 
algorithm  necessary  to  solve  this  problem,  let  us 
consider  the  following  definition: 

Def  in  it  ion.  Assume  T  is  a  task  assigned  to 
an  interior  node.  Anv  other  task  is  said  to  be 
a  logical  neighbor  of  T  if  and  only  if  it  shares 
data  with  task  T. 

Notice  that  in  the  above  example,  refer  to 
Figure  1,  the  task  at  point  1  and  at  point  2  are 
logical  neighbors  hut  the  task  at  points  1  and  A 
are  not  logical  neighbors.  An  algorithm  mav  now 
he  given 

Algorithm.  For  k*1 ... i terat ion-1 imi t 


1. )  Solve  for  u(T,k+i). 

2. )  Send  u(’C,k+l)  to  its  logical  neighbors. 

3. )  If  there  is  no  significant  difference 

between  the  present  and  past  iterates 
raise  this  node's  convergence  flag 
i.e.  [  |u(T,k+l)-u(T,k)|  \<e  for  some 
e>0 . 

A.)  If  all  the  tasks  have  raised  their  con¬ 
vergence  flags,  then  it  is  finished  else 
continue . 

5.)  Accept  u(N,k+l)  from  task  T's  logical 
neighbors  N. 

The  equations  for  the  updates  at  the  interior 
nodes  were  given  in  (7).  Notice  how  the  tasks  for 
neighboring  nodes  located  at  1  and  A  must  send 
their  updated  values  to  that  task  associated  with 
the  node  3  etc . . . 

The  Ada  code  for  such  a  system  is  for  the 
most  part  straightf orward  with  the  more  chal¬ 
lenging  port;on  being  the  design  of  the  commun¬ 
ication  paths  between  the  various  tasks  and  Ce 
protection  of  the  convergence  flag.  Figure  2  illus¬ 
trate  the  communication  channels  used.  Both  of 
these  ideas  car.  trace  their  origins  to  Hibbard 
et  all6. 

It  is  worth  noting  that  it  is  necessary 
for  the  coordinator  to  accumulate  all  the  neces¬ 
sary  updated  values  from  all  neighboring  tasks 
before  they  are  sent  to  the  proper  interior 
node  task  which  the  coordinator  is  coordinating. 
Furthermore,  the  convergence  flag  is  maintained 
in  a  protected  task  and  it's  code  may  appear  as 
follows : 

Example  2. 

task_type  Protected  Convergence-Counter  is 
entry  Ini tial i ze_Counter (Z  :  in  integer); 
entry  Increment_Counter (Z :  in  integer:=l); 
entry  Decrement_Counter (Z :  in  integer:=l); 

end  Pro  tec  ted__Conver  gene  e_Counte  r ; 

task  body  Pro  tec  ted__Convergence_Counter  is 
Convergence^  Counter :  integer; 

begin 

accept  Ini tiali ze_Counter (Z:  in  integer) 
do 

Convergence_Counter  :=Z; 
end; 
loop 
select 

accept  Increment  Counter(Z:  in 
integer:=l)  do 

Convergence_Counter : Convergence- 

Counter  +  Z; 
end  ; 
or 

accept  Decrcment^Counter (Z :  in 
integer:=l)  do 

Convergence^  Counter :  Convergence^ 

Counter  -  Z; 
end  ; 
or 

accept  Read  Counter (Z ;  out  integer: 

=  1  )  do 

Z:  Convergence Counter ; 
end ; 
or 

terminate; 
end  select; 
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cti'i  I  ; 

it'd  I’  l t  «  t  ed  l  iMIVi-I  I'l'IliT  'iMiut-.r; 
a'mi-  Liu  initial  i.-«  counter  i  s  equal  t*>  the 
.  u-.S  r  region,  Kim’  u.ii!.  In  our  mode  1 ,  ther  ■ 
II  foil!  tiu-.il>!!:. 

"1'vi.  ii-.lv,  the  delay  in  Figure  2  caused  bv 
tin  * «  n.’i  vvous  with  nr  i  ghhor  i  ng  tasks  htronu-H 
":tTi  not [cable  .is  tli*.-  stencil  becomes  more  coro- 
:  !e\.  if  r  rv.ii-ipK  ,  the  elliptic  partial  diiter- 
<  :;t.  i  il  equation  at  t  K  !orm  (2)  with  a  being 
n*  n-  -t  ro  vi>  Ms  a  stone  il  of  the  form; 


Figure  (b). 

wIkTi1  each  interior  mule  lias  eight  neighbors, 
ili'iu'i',  tiio  rendezvous  proooss  bocomos  more  in¬ 
volved  and  perhaps  more  time  consuming  depend¬ 
ing  on  the  cost  of  a  rendezvous  in  Ada*  i.o., 
there  are  eight  logical  neighbors  with  which  a 
task  coordinator  must  have  rendezvoused  prior  to 
t'ede/.vous  i  ng  with  the  task  for  which  it  is 
coord inat ing . 

For  more  spacious  problems,  inner  square 
regions  are  used  rather  than  nodes.  The  geo¬ 
metric  picture  which  would  appear  as  in  Figure  1 
where  the  interior  dots  illustrate  interior 
nodes  of  tlu-  interior  regions.  In  our  previous 
example  each  interior  node  is  a  region. 

! V .  Asynchronous  Approach. 

With  the  understanding  that  the  above  .so¬ 
lution  was  complicated  by  the*  extensive  up¬ 
dating  of  the  boundaries  of  the  region,  a  second 
approach  was  taken  by  Baudot  . 

Motivated  by  previous  work  on  chaotic  re¬ 
laxation*'',  be  developed  an  asynchronous 
approach  to  the  solution  of  (2).  Briefly,  the 
idea  is  to  perform  various  computations  in 
parallel  and  to  utilize  shared  memory  in  order  to 
avoid  the  manv  task  rendezvous.  The  benefit  of 
such  an  approach  is  the  avoidance  of  the  over¬ 
head  used  by  tasks  wlu-n  a  rendezvous  is  per¬ 
formed.  The  cost  is  that  one  task  may  run  sig¬ 
nificantly  faster  than  the  other  resulting  in  an 
unususal  number  of  extra  computations. 

With  this  in  mind  let  us  consider  Baudot's 
'll ut ion  of  the  LaPlace  equation  as  modified  hv 
Hibbard  et  all”.  In  this  approach,  access  is 
available  to  all  the  variables  of  the  matrix 
(shared)  and  updates  arc  done  at  will.  An  algo¬ 
rithm  for  this  approach  is  the  following: 

A !g o r i t hm .  For  k- 1 . . . iterat inn-1 imi t  do 

1. )  Solve  for  u(T,k+l). 

2. )  If  there  is  no  significant  difference 

between  the  present  and  past  iterate 
raise  the  convergence  flag  for  that 
region. 

J, )  If  all  the  region's  convergence  flags 
are  raised  then  it  is  finished  else 
cor.t  inue . 

Since  the  array  u(i,j)  are  shared  variables 
there  is  no  need  to  communicate  the  updates  be- 


tueiM  tasks.  However ,  the  tasks  must  communicate 
with  a  central  task  where  the  pro  tec ted-conver- 
gem-*— counter  resides.  This  fosters  tlu*  need  for 
a  coordinator  task  for  each  task.  Figure  4  ex¬ 
plains  this  common icat ion. 

The  communicat ion  with  each  of  the  coordi¬ 
nators  as  depicted  in  Figure  4  can  get  more  in¬ 
volved  as  the  stem*  i I  is  more  involved  as  in 
Figuri  (b) .  Note  that  the  coordinator  task  is  not 
required  to  rendezvous  with  the  other  region  tasks 
as  in  Figure  2.  Since  all  the  region  tasks  access 
the  shared  discretized  values  u(i,j)  without  anv 
additional  protocol,  this  may  lead  to  some  unfore¬ 
seen  difficulties.  The  effects  of  simultaneous 
access  to  a  shared  variable  are  discussed  in 
section  9.11  of  the  Ada  language  reference  manual'4 
where  strong  words  of  warning  are  given  to  those 
who  violate  the  assumptions  given  therein.  Spec¬ 
ifically,  some  shared  variables  while  being  read 
bv  one  task  may  be  read  incompletely  due  to  the 
1  ai- 1  that  it  is  also  being  written  by  another 
task.  Hence,  tlu-  read  may  receive  a  value  that 
is  neither  the  previous  value  of  the  variable  nor 
the  new  value.  Obviously,  for  the  solution  to  be 
reasonable  requires  that  the  operation  of  reading 
and  writing  the  shared  variable  be  indivisible 
with  respect  to  each  other.  There  are  other  dif¬ 
ficulties  with  tliis  shared  variable  approach. 

See  Hibbard  et  a  1 1 b . 

V  .  Mu.l_t  i -Col  o r  i  njj . 

Consider  the  model  problem  (4),  partitioned 
as  *n  Figure  1,  the  grid  points  by  the  Red/ Black 
schemes  as  shown  in  Figure  5.  The  Red  points  are 
numbered  from  left  to  right,  bottom  to  top  fol¬ 
lowed  by  the  black  grid  points  in  the  same  fash¬ 
ion.  As  in  Young* -  [p.271],  the  difference  equa¬ 
tions  mav  be  written  in  the  partitioned  matrix 
form 


where  P  is  the  diagonal  matrix  and  u  and  u, 

r  b 

denote  the  vectors  of  unknowns  associated  with  the 
red  and  black  grid  point  respectively.  The  iter¬ 
ation  scheme  can  be  easily  written  as 
Du.  =  -CTu  +  g 

»  '  ■’  (9) 

l)u  =  -Cu,  +  h 
r  b  r 

and  each  part  of  (9)  can  be  effectively  implement¬ 
ed  bv  Ada  task.  Again,  the  coordinator  approach 
is  adopted  with  a  communication  pattern  as  in 
Figure  b  where  the  usual  centrally  located  pro¬ 
tective  counter  is  utilized. 

An  algorithm  where  C  is  a  color  and  N  is  an 
adjoining  color  is 

Algorithm  3.  For  k= 1 , 2 . . . i terat ion-1 imi t  do 
1  . )  Sol  v»*  for  u(k+l  ,(')  . 

2.)  Send  u(k+l,C)  to  a  logical  neighbor’s 
coord i nator . 

1.)  Receive  u(k+!,N)  from  the  task's  own 
coord i nator . 

4.)  If  there  is  no  significant  difference 
between  u(k+l,C)  and  u(k,C)  raise  the 
convergence  flag. 
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5.)  If  iill  tasks  have  raised  their  converg¬ 
ence  flags,  then  it  is  finished  else 
ront i nue . 

['he  stencil  of  figure  (h)  may  also  he  color¬ 
ed  »ith  a  red/Mack  coloring  while  more  compli¬ 
cated  stencils  may  require  more  complicated  color¬ 
ing  patterns. 

Of  course,  we  have  just  touched  the  surface 
of  the  coloring  approach  for  more  complicated 
stencils  one  derives  more  complicated  coloring. 

The  mut i-colur ing  approach  lias  been  puursued  by 
I.. Adams  in  what  seems  to  be  the  start  of  a  huge 

project.  In  that  thesis,  various  iteration  meth¬ 
ods,  e.g.  SOR  and  SSOR  among  others  are  consid¬ 
ered.  The  Numerical  experimentation  was  done 
on  the  Finite- Element  Machine. 

V I  .  Cone  1 1 is  ion . 

The  above  methods  are  intended  for  use  with 
an  implementation  of  Ada  on  a  multiprocessor 
system,  that  will  have  some  number  P  of  process¬ 
ors.  Our  N  Ada  tasks  (2r+l  where  r  is  the  num¬ 
ber  of  regions/colors)  will  be  scheduled  onto 
these  processors  by  the  underlying  Ada  system. 
Suppose  that  P  is  less  than  N,  or  even  that  P 
is  equal  to  1.  The  above  methods  can  be  execut¬ 
ed  correctly  jjjrrogardloss  of  the  number  of  pro¬ 
cessors  that  are  devoted  to  a  program  and  even 
executed  on  a  single  processor.  Furthermore,  if 
this  he  the  ease  then  the  results  can  be  inter¬ 
preted  in  such  a  way  as  to  guarantee  the  results 
when  the  code  is  moved  to  another  system. 
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This  demonstrates  a  method  by  which  a  small 
college  computer  science  department  can  intro¬ 
duce  Ada  into  the  curriculum  without  the  burden 
of  costly  additions  to  its  faculty.  It  is  sug¬ 
gested  that  such  a  department  should  enlist 
the  support  of  non-computer  science  departments 
as  conveyors  of  Ada  in  the  Problem  domain. 

The  example  cited  here  illustrates  Ada  as  a 
vehicle  to  describe  a  statistical  problem  in 
data  analysis. 


This  is  intended  to  address  the  challenge  to  the 
computer  science  program  of  the  small  college 
presented  by  the  technological  changes  brought 
forth  by  the  Ada  programming  languages.  Undoubt¬ 
edly  the  introduction  of  Ada  will  spawn  sweeping 
changes  in  software  technology,  for  otherwise 
the  Ada  initiative  will  have  been  a  massive  fail¬ 
ure.  Small  colleges  will  be  hard  pressed  to  in¬ 
stantly  accommodate  such  program  perturbations 
without  an  increase  in  faculty  size. 

A  close  examination  of  the  situation,  however, 
suggests  that  the  outlook  may  not  be  as  dismal 
as  it  appears  on  the  surface;  to  the  contrary, 

Ada  may  indeed  force  us  to  develop  a  curriculum 
which  will  better  serve  the  interest  of  the  stu¬ 
dent  and  the  nation  at  large.  Traditionally  the 
computer  sc  iencc  department  at  a  small  liberal 
arts  college  has  grappled  with  the  dual  mission: 

1)  educate  the  student  with  sufficient  breadth 
and  depth  in  the  theoretic.il  framework  of  computer 
science  -Jo  that  he/she  can  cope  with  graduate 
school;  1}  to  provide  practical  experience  in 
applications  sufficient  to  prepare  the  student 
f . > r  immediate  employment.  Vet,  in  many  cases, 
each  graduate  tend  to  be*  strongly  skewed  toward 


one  of  those  two  poles,  despite  the  diligent 
efforts  of  his  department  to  promote  some  balance 
between  then.  By  the  time  he  graduates,  the 
student  who  prefers  applications  to  theory  is 
usually  a  programmer  delux,  who  hacks  away  at  his 
stylized  code  in  a  dialect  that  only  he  can  fully 
comprehend.  Now,  if  Ada  can  successfully  modify 
such  behavior  among  the  practical  software  de¬ 
velopers,  then  surely  it  must  be  of  some  benefit 
to  the  student  before  his  poor  habits  are  formed. 

It  is  suggested  here  that,  first  and  foremost,  the 
computer  science  major  should  be  trained  to  be¬ 
come  a  good  problem-solver.  He  should  he  well- 
informed  that  though  his  solution  may  be  cast  in 
a  computer  science  context,  his  problem  usually 
has  roots  in  mathematics,  science,  engineering, 
or  business.  With  this  approach  it  not  only  will 
encourage  the  computer  science  major  to  develop 
a  stronger  appreciation  for  non-computer  science 
subject  matter,  but  it  may  also  pursuade  the 
computer  science  department  to  forge  stronger  tie* 
with  other  departments.  The  introduction  of  Ada 
and  software  engineering  techniques  into  t'n 
undergraduate  curriculum  may  provide  the  impetus 
and  the  opportunity  to  implement  this  strategy. 

It  is  suggested  here  that  the  computer  science 
department  in  the  small  college  targets  its 
initial  Ada  training  program  to  the  mathematics, 
business,  and  science  faculty  members.  Emphasis 
should  be  put  on  the  design  goals  of  Ada,  with 
some  hands-on  experience  with  Ada  as  a  programming 
language.  The  computer  science  department  should 
provide  numerous  examples  from  each  area  of  pro¬ 
blems  to  be  spec  if ied  in  Ada.  By  so  doing,  the  de¬ 
partment,  with  the  support  of  other  faculty,  can 
immediately  place  Ada  in  the  problem  domain  for 
the  student.  The  student  would  then  bring  to 
the  computer  science  course  some  knowledge  of  the 
structure  of  Ada  as  well  as  a  readiness  to  apply 
Ada  in  the  solution  domain. 

Statistics  courses;  which  computer  science  majors 
are  generally  required  to  take,  are  cited  as  an 
example  of  fertile  ground  for  this  kind  of  appli¬ 
cation.  Ada  may  be  used  to  describe  the  problem, 
the  data  base  and  the  associated  analytical 
models.  The  instructor  may  do  this  without  im¬ 
pairing  his  freedom  to  specify  a  method  of  solu¬ 
tion.  He  may  specify  that  the  problem  be  solved 
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manually,  by  a  computer  program  written  in  OFR- 
TRAN  or  some  other  suitable  language,  or  by  a 
computerized  statistical  package.  The  point  here 
is  that  the  exposure  Co  Ada  in  a  multi-discipline 
problem-solving  environment  may  produce  a  more 
disciplined  and  resourceful  itware  level oper/ 
designer  than  the  traditional  une-d  {mens  Lon.i  I 
prospective  provided  bv  the  computer  science 
department  alone. 

The  following  is  an  example  ot  problem  spec i t  ica- 
t ion  through  Ada. 

Program  Un_i  t  Spec  if  lea t  ion 

With  DATAENTRY;  with  DATA  RANKS;  with  Sl’M  OF 
SOLARES;  PACKAGE  ANALYSIS,  OF  VARIANCE  use 
LA  I A_ ENTRY ; 

Problem:  statistical  data  analysis 

data  source:  tree  population  an  a  soul h  cen¬ 
tral  Georgia  plantation  the  ex¬ 
periment  span  a  j l -year  period 
objective:  Compare  seed  lots  relative  to 

survival  and  growth  charact  jo  ¬ 
ist  i  c  s 

model:  Randomized  Block  Design 


Type  PLANTATION 
record 

Piot_NUMBER: 

TREE 

SEED  LOT  : 


is 

INTEGER  range  1 . .9999  ; 

INTEGER  range  1 . .99; _  tree  no. 

within  plot 

INTEGER  range  1..9999; _  seed 

source 


REPLICATE 

NPLOT 

HEIGHT  3 

HEIGHT  3 

HEIGHT  10 

HEIGHT  !M 

D  l  AM  10 

D 1 J1 


INTEGER; 

INTEGER; 

no . 

of 

seed  1 ings 

plat  ed  i  n 

i  p  1  o  t 

REAL; 

he 

ight 

in 

ft 

.  at  age 

1 

years 

REAL; 

he 

ight 

i  n 

f  t 

.  at  age 

3 

years 

REAL; 

lu¬ 

ight 

in 

!  t 

.  at  age 

1  0 

yea  rs 

REAL; 

be 

ight 

in 

meters  at  a 

ge 

2\  years 

REA  I.; 

breast 

-hi) 

,:h 

d  iamet or 

:  n 

in.  at  at! 

:e 

10  yea r 

s 

REAL; _ 

hr 

east 

— 'Vi  i  j 

d i amet er 

in 

cm  at  agt. 

,  > 

1  ye. 

ars 

end  record; 

PLOT  MEMBER  is  exper  inu-nta  I  unit 
suggested  method:  Analysis  of  variance 
( a  s same  no rma 1 i t  y ) 

suggested  alterative:  Friedman  ANOVA  by  ranks 
( Conscrv.it  i  v c  ' 

type  fixed  is  DELTA  0.01  ..999.99 

ANOVA  IT. ST  STATISTIC:  FIXED 
*  R I  EDM  TEST  STATISTIC:  FIXED 

end  ANALYSIS  OF  VARIANCE; 
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ADA  AS  A  PRODRAM  DESIGN  LANGUAGE  —  HAVE  THE  MA.JOR  ISSUES  BEEN 
ADDRESSED  AND  ANSWERED? 


hobert  M  Blasewitz 
RCA  Government  Systems  Division 
Missile  and  Surface  Radar 
Moorestown,  New  Jersey 


Summary 


J  Department  of  Defense  requirements  to  use  the  higher  order 
language  Ada*  will  create  challenges  to  developers  of  mili¬ 
tary  software  that  encompass  these  major  concerns:  i  X  i  de¬ 
veloping  a  core  of  Ada  software  personnel,  i2i  achieving 
productivity  and  software  gains  that  have  been  targeted  as 
Ada  life-t"  ele  objectives,  and  1 3 >  transitioning  to  a  language 
that  embodies  a  capability  to  express  software  solutions  elo¬ 
quently.  clearly,  reliably  and  efficiently.  Ada  is  more  than  a 
programming  language,  it  is  the  basis  for  a  modern  perspec¬ 
tive  of  software  design  and  engineering.  The  IEEE  working 
group  on  Ada  as  a  PDL  has  been  addressing  the  issues  in¬ 
volved  with  the  use  of  Ada  as  a  design  mechanism  for  nearly 
two  years.  This  working  group  has  recently  generated  a 
draft  guideline  that  addresses  the  key  issues. 

The  extent  of  industry's  involvement  with  Ada  POLs  and  the 
status  and  final  form  of  the  IEEE  product  will  substantially 
impact  both  the  a.ceptance  of  the  Ada  language  and  the 
efficiency  and  correctness  of  its  use.^ 

Introduction  —  Program  Design  Languages  and  Ada 


During  the  past  several  years,  industry  has  seen  an  explo¬ 
sion  in  the  cost  of  generating  and  maintaining  software,  cou¬ 
pled  with  a  decline  in  the  quality  and  reliability  of  the  soft¬ 
ware  product  A  need  for  a  radically  different  approach  to  the 
development  of  software  is  readily  apparent 

One  of  the  first  tools  for  documenting  software — the  flow¬ 
chart —  was  developed  from  the  belief  that  a  program  should 
be  documented  after  it  is  written  Today,  the  view  is  that 
program  design  and  documentation,  at  the  very  least,  must 
precede  coding 

A  current  tool  for  software  design  and  documentation  is  the 
program  design  language  1  PDL>  PDLs  are  based  on  a  com¬ 
mon  theme  of  software  engineering  that  complex, technical 
developments  require  an  iterative  approach  Other  noted 
reasons  for  the  use  of  PDLs  include: 

1.  productivity  is  increased,  since  the  PDL  can  be  used  as  a 
design  documentation  that  can  be  used  by  ancillary 
tools  to  check  for  completeness  and  consistency 


*Ada  is  a  registered  trademark  of  the  l"  S  (government  Ada  Joint  Pro¬ 
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2.  communication  complexity  is  reduced  since  the  PDL  fa¬ 
cilitates  communication  at  the  proper  level  and  in  the 
required  detail  throughout  its  use 

3.  a  single  notation  can  be  utilized  that  expresses  design 
throughout  all  phases  of  the  software  life  cycle 

4.  software  quality  gains  are  facilitated  by  the  early  detec¬ 
tion  and  correction  of  errors  in  the  design  process. 

Although  most  PDLs  consist  of  a  mixture  of  language-ori¬ 
ented  control  key  words  and  English-like  statements  to  con¬ 
cretely  describe  an  abstract  design  and  concurrently  support 
the  above  goals,  other  support  objectives  can  also  be  noted: 

1.  focus  attention  on  appropriate  levels  of  design  detail 
without  becoming  overwhelmed  with  minor  issues 

2.  provide  a  process  that  is  amenable  to  the  creation  of 
well-structured  programs 

3.  replace  flowcharts  and  other  difficult  software  tools 
with  an  efficient  approach  to  software  production 

4.  provide  a  natural  transition  from  high  levels  of  logic 
abstraction  into  detailed  code 

5.  facilitate  program  logic  documentation  and  mainte¬ 
nance. 

Although  not  all  PDLs  accommodate  support  by  tools,  some 
provide  listings  indented  according  to  the  logic  and  program 
structures,  cross-reference  listings  for  names  and  subpro¬ 
grams.  and  detection  of  structure  delimiters.  In  the  past, 
many  different  classes  of  design  aids  have  been  referred  to  as 
PDLs.  These  include  graphic  approaches  such  as  H1PO  and 
structured  flow  charts;  requirements  oriented  tools  such  as 
the  Software  Specification  Language  and  the  Problem  State¬ 
ment  Language;  mathematical  representations  of  design 
such  as  Higher  Order  Software  Specification  and  the  P  and  V 
notations;  and  programming  language-oriented  tools  such  as 
the  Caine.  Farber  and  Gordon  PDL,  the  IBM  PDL.  and  the 
Program  Design  and  Documentation  Language.  Most  of 
these  approaches  can  be  eliminated  from  consideration  as 
true  PDLs,  except  for  the  classes  involving  graphic  represen¬ 
tation  and  programming  language-oriented  methods 

Both  of  these  methods  place  primary  emphasis  on  describing 
software  algorithms  or  data  Programming  language-ori¬ 
ented  PDLs  are  a  special  class  in  themselves,  in  that  they 
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are  easily  adapted  to  a  computer-based  development  scheme 
PDL  descriptions  can  be  easily  entered  and  refined  with  a 
simple  text  editor  In  fact,  if  the  PDL  is  based  on  the  imple¬ 
mentations  programming  language,  the  source  code  can  be 
created  directly  from  the  PDL  description  using  the  text  edi¬ 
tor 

The  work  that  has  been  initiated  by  the  IEEE  working  group 
on  Ada  as  a  PDL  has  focused  on  resolving  the  issues  associ¬ 
ated  with  using  Ada  as  a  program  design  language.  Ada  is  a 
prime  candidate  for  a  PDL  since  it  meets  most,  if  not  all,  of 
our  requirements  for  a  PDL  as  stated  previously.  It  is  also  of 
importance  because  of  recent  government  direction  to  use 
Ada-based  PDLs  in  responding  to  RFPs.  The  IEEE  product, 
at  the  present  time,  specifies  the  features  or  characteristics 
of  a  design  language  that  is  based  on  the  syntax  and  seman¬ 
tics  of  the  Ada  programming  language  (ANSI/MIL  STD 
1815A).  A  design  language,  as  defined  by  the  working  group, 
is  a  textual  language  for  the  precise  and  concise  expression 
of  program  design  and  one  which  provides  a  friendly  vehicle 
for  communicating  and  expressing  software  designs.  The  de¬ 
sign  language  is  a  tool  to  be  used  throughout  the  life  cycle  of 
the  product;  it  must  be  simple,  human  engineered,  precise, 
verifiable,  and  supportive  of  existing  program  methodologies 
to  the  same  extent  that  Ada  supports  these  design  concepts. 

The  current  Ada  as  a  PDL  guide  includes  direction  on  the 
following  major  issues  involved  with  program  design: 

•  life  cycle  support 

•  methodology  of  support  for  life  cycle 

•  features 

•  properties 

•  support  mechanisms 

•  language  issues 

•  development  support  environment 

•  human  factors  issues 

•  management  issues 

•  PDL  alternatives 

The  present  product  does  not  specify  the  following  elements: 

•  a  single  Ada  design  language  syntax 

•  the  programming  language  or  group  of  programming 
languages  in  which  the  system  described  in  the  design 
language  text  is  to  be  implemented 

•  any  system  methodology  to  be  adopted  under  the  Ada 
design  language 

•  the  system  or  method  bv  which  design  language  text  is 
represented,  stored  or  processed 

The  selection  of  either  a  guideline,  recommended  practice,  or 
standard  is  accomplished  by  means  of  a  consensus  of  techni¬ 
cal  opinion  within  the  IEEE  working  group 


This  group  is  directing  its  efforts  to  avoid  any  damaging 
effects  on  present  corporate  investments  in  PDL  design 
However,  the  IEEE  guideline  will  be  directly  influenced  by 
the  lessons  learned  from  these  developers  and  will  hopefully 
bring  together  the  wide  scope  of  work  in  the  PDL  area.  The 
availability  of  a  PDL  tool  in  the  Ada  Programming  Support 
Environment  will  also  foster  development  of  DoD  software 
throughout  the  life-cycle  of  the  software,  if  such  an  end  prod¬ 
uct  can  be  realized  in  a  timely  fashion.  (Some  of  the  technical 
problems  associated  with  the  IEEE  effort  will  be  detailed 
throughout  this  report.) 

Program  Design  Languages  —  Why  a  Common  Ada  PDL? 

The  major  issues  of  modern  software  development  stem  from 
the  costs  of  software  development,  use  and  maintenance.  The 
growth  of  the  software  development  process  has  shown  a 
chaotic  pattern  from  the  beginning.  Even  now,  after  25 
years,  we  find  little  conformity  in  the  specifics  of  software 
development.  It  is  also  clear  that  there  are  not  enough 
trained  software  professionals  to  meet  today’s  demand  And 
this  situation  is  steadily  growing  worse.  These  issues  have 
become  increasingly  clear  in  recent  years,  virtually  crying 
out  for  an  intelligent,  planned  approach  to  the  problems.  The 
United  States  Department  of  Defense,  largely  because  of  the 
visibility  of  its  needs  in  this  area,  took  the  lead  in  the  mid- 
1970s  by  sponsoring  development  of  the  Ada  language, 
which  directly  addressed  the  major  "software  crisis"  issues 
The  objectives  of  the  Ada  language  aie  summarized  here  to 
illustrate  the  common  thread  of  interest  between  the  ration¬ 
ale  for  the  Ada  language  and  a  common  program  design 
language  based  on  Ada. 

DoD  initiated  the  Ada  program  to  save  taxpayer  money 
through  standardization.  These  savings  will  come  from  the 
portability  of  reuse  of  operational  software,  more  effective 
use  of  support  software  (such  as  program  design  language), 
improved  programmer  productivity,  and  reduced  software 
maintenance.  There  is  little  question  that  the  entire  soft¬ 
ware  industry  is  in  need  of  a  modern,  efficient,  and  highly 
portable  system-implementation  language  and  toolset.  Tech¬ 
nical  arguments  about  which  language  is  best  really  miss 
the  point,  for  only  Ada  and  its  accepted  toolset  will  benefit 
from  DoDs  investment  in  standards  enforcement. 

Traditionally,  a  Program  Design  Language  (PDLi  has  been  a 
means  for  program  description  and  recording.  It  is  now  be¬ 
lieved  that  a  PDL  need  not  be  limited  to  these  two  activities. 
The  scope  of  the  PDL  should  be  expanded  to  include  correct¬ 
ness  assessment  and  possibly  the  reusability  of  designs 
Ada's  strong  typing,  packaging  mechanism  for  interface  def¬ 
inition,  and  scope  and  visibility  rules  provide  for  increased 
checkability  of  design.  Therefore,  the  increased  analysis  pro¬ 
vided  by  an  analyzer  of  a  rigorously  defined  PDL  based  on 

Ada  should  result  in  both  increased  reliability  and  main¬ 
tainability  of  delivered  systems,  while  fostering  a  superb 
means  of  communicating  the  design  process  The  incorpora¬ 
tion  of  increased  analysis  of  a  PDL  emphasizes  the  incre¬ 
mental  validation  or  at  least  verification  of  a  design  during 
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the  design  process.  The  need  for  such  aid  need  not  be  re¬ 
peated  here;  it  is  obvious  that  early  detection  of  design  errors 
in  the  software  life  cycles  is  critical  to  schedule  and  cost 
constraints. 

Ada  is  new  and  relatively  untested  as  a  PDL.  but  neverthe¬ 
less  meets  most  of  the  requirements  of  a  design  language. 
Although  Ada  programs  are  not  particularly  easy  to  write, 
the  complexity  of  the  language  exists  largely  to  enforce  good 
programming  practices. 

The  major  progam  design  features  supported  by  Ada  include: 

•  packages 

•  subprograms 

•  generics 

•  tasks  and  task  types 

•  exception  handling 

•  comments 

•  pragmas 

•  types 

•  stubs 

These  features  are  extremely  important  to  the  support  of  the 
design  process,  hut  it  should  be  noted  that  it  is  the  total 
collection  of  these  features  and  their  interaction  that  pro¬ 
vides  for  potential  improvement  in  the  existing  design  proc¬ 
ess.  In  the  interest  of  brevity,  only  a  few  of  these  support 
mechanisms  will  be  explained  here. 

The  concept  of  the  Ada  package  is  thought  to  be  the  lan¬ 
guage's  principal  contribution  to  the  programming  science. 
Packages  permit  a  user  to  encapsulate  a  group  of  logically 
related  entities.  Through  the  use  of  two  package  components 
(the  specification  and  body',  packages  directly  support  the 
software  principles  of  data  abstraction,  information  hiding, 
modularity,  and  localization  Programmers  can  apply  these 
principles  in  other  languages,  but  Ada  packages  encourage 
and  enforce  these  principles.  Since  the  specification  and  body 
may  be  compiled  separately,  it  becomes  an  easy  matter  to 
create  the  specification  early  in  the  software  design  process 
and  then  later  to  add  the  body  as  details  about  the  low  level 
operations  are  specified  Possibly  most  important,  Ada  pack¬ 
ages  aid  in  the  process  of  controlling  the  complexity  of  soft¬ 
ware  solutions  bv  providing  a  mechanism  with  which  to 
physically  partition  related  entities  into  a  logical  groupings. 

Ada's  strong  typing  mechanism  allows  a  user  to  define  a  set 
of  values  that  objects  may  assume  as  well  as  the  set  of  opera¬ 
tions  that  may  be  performed  on  them 

The  effects  of  strong  typing  enable  both  domain  and  opera¬ 
tion  checking  at  compile  time,  rather  than  at  execution  time. 
The  goals  of  strong  typing  for  a  language  apply  directly  to 
the  design  language  also.  These  goals  include  factoring  of 
properties,  abstraction,  and  reliability  The  interested 
reader  may  read  of  these  goals  directly  from  the  DoD's  Ra¬ 
tionale  For  The  Design  of  the  Green  Programming  Lan¬ 
guage 


The  generic  is  a  reusable  structure  with  an  abstract  parame¬ 
ter  list  in  its  definition  It  can  be  viewed  as  an  extension  of 
the  familiar  "macro"  concept  Generics  provide  a  general 
facility  for  establishing  translation  time  parameters  for  pro¬ 
gram  units,  thereby  promoting  reusability.  The  concept  of 
reusability  portability  promoted  by  generics  is  valuable  for 
many  reasons,  including: 

1.  tested  generic  programs  are  stable  and  reuseable 

2.  they  provide  the  concept  of  an  Ada  components  industry 

3.  generic  programs  need  never  be  redesigned  or  retested. 

All  of  these  features  illustrate  their  value  in  a  design  process 
—  designs  tend  to  become  more  stable  as  the  use  of  tested 
and  stable  components  are  used  as  the  basis  for  design. 

Other  features  of  Ada  that  support  design  include  exception 
handling  and  tasking.  Exception  handling  provides  a  com¬ 
plete  description  of  a  software  system  under  error  conditions 
as  well  as  the  system's  response  to  these  error  conditions.  It 
encourages  a  designer  to  define  and  to  handle  error  condi¬ 
tions.  The  Ada  tasking  model,  including  rendezvous,  task 
elaboration  and  activation,  and  allocators,  provides  a  natu¬ 
ral  means  by  which  real-time  systems  can  be  described 

Tasks  can  be  viewed  as  independent,  concurrent  operations 
that  communicate  with  each  other  by  passing  messages  for 
real-time  applications.  Ada  provides  this  strong  facility  for 
multi-tasking  or  for  logically  parallel  threads  of  execution 
that  can  cooperate  in  a  controlled  manner. 

Last,  but  not  least,  is  the  Ada  commenting  mechanism 
which  provides  an  indispensable  means  for  adding  annota¬ 
tions  to  the  language.  Extensions  provided  by  the  comment 
mechanism  have  the  advantage  that  an  Ada  compiler  can  be 
used  to  process  the  design  language  text;  the  design  docu¬ 
mentation  can  also  be  combined  with  its  implementation 
and  conveniently  updated  during  maintenance  and  design, 
in  summary,  the  use  of  English  within  an  Ada  PDL  provides 
representation  of  high-level  design  information  that  can  be 
later  refined  to  a  more  detailed  description.  There  is,  how¬ 
ever,  a  substantial  amount  of  debate  remaining  on  both  the 
substance  of  allowable  comments  and  their  syntax.  This  is¬ 
sue  will  be  addressed  in  the  "Outstanding  Issues”  section  of 
the  paper 

This  short  overview  has  illustrated  how  the  same  features 
that  make  Ada  so  desirable  as  a  language  also  enforce  its 
choice  as  a  design  language  Ada  is  very  rigorous;  therefore 
using  it  in  the  early  phases  of  the  life  cycle  provides  the 
capability  of  enforcing  analysis  and  design  compliance  at  a 
time  when  the  most  costly  errors  are  propagated.  As  far  as 
possible,  the  system  architecture  should  be  described  using 
the  constructs  provided  by  Ada  instead  of  the  less  cohesive 
form  provided  by  comments. 

There  is  a  real  danger  that  highly  detailed  commentary  may 
actually  lull  the  reader  into  the  dreaded  "tar  pits”  of  having 
code  that  does  not  match  the  intent  of  the  programmer  — 
that  is.  a  design  that  can  be  interpreted  in  more  than  one 
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way  and  is  termed  ambiguous  or  imprecise.  Since  Ada  is 
machine  analvzable.  the  syntax  and  static  semantics  speci¬ 
fied  bv  the  language  rules  can  be  checked  and  analyzed  by 
an  Ada  compiler  alone  A  stronger  statement  along  these 
lines  will  illustrate  that  an  Ada  POL  also  provides  early- 
prototyping.  dynamic  semantic  checking  and  automatic  sim¬ 
ulation  since  it  is  an  executable  language. 

The  final  solution  to  the  basic  problems  of  the  software  crisis 
lies  in  applying  modern  software  methodologies,  such  as 
POLs,  that  are  supported  by  a  higher-order  language,  such 
as  Ada.  that  encourages  and  enforces  these  principles.  The 
coupling  of  Ada  with  an  Ada-based  PDL  offers  the  software 
industry  a  significant  inroad  into  the  solution  of  the  software 
crisis  and  its  inherent  problems. 

Outstanding  Issues  Involving  Ada-Based  PDLs 


It  can  be  safely  said  that  the  current  PDL  efforts  using  Ada 
as  a  base  language  vary  in  the  degree  of  rigor  with  which 
they  use  Ada  They  vary  in  form  from  Ada  with  comments 
i  where  the  semantics  and  non-procedural  description  are  in¬ 
cluded  in  the  comments!  to  Ada  intensive  descriptions.  Al¬ 
though  there  is  clearly  no  agreement,  as  yet,  on  the  exact 
form  of  a  unique  Ada-based  PDL.  there  is  general  enthusi¬ 
asm  and  agreement  that  key  elements  of  the  Ada  language 
directly  support  program  design. 

Advocates  for  using  a  subset  of  Ada  as  a  PDL  usually  en¬ 
dorse  the  inclusion  of  English  descriptive  phrases  in  the  PDL 
descriptions.  The  syntax  and  semantics  for  the  English  de¬ 
scriptions  can  vary  greatly,  thereby  loosening  the  rigor  and 
increasing  the  possibility  of  ambiguity.  The  exclusion  of  fea¬ 
tures  from  the  subsets  is  also  a  touchy  affair,  for  possibly  the 
very  features  eliminated  in  the  subset  may  be  required  for  a 
particular  design 

Another  area  of  concern  is  the  use  of  annotations.  Annota¬ 
tions  usually  fall  into  two  distinct  categories:  those  that  sup¬ 
port  a  methodology,  and  those  that  support  a  design  tool.  The 
Ada  PDL  descriptions  with  annotations  generally  try  to  stay 
within  the  bounds  of  Ada  syntax  so  that  the  PDL  descrip¬ 
tions  can  be  compiled  The  annotations  are  generally  forms 
of  Ada  comments  and  have  semantic  restrictions  relative  to 
other  Ada  language  elements  PDLs  described  with  annota¬ 
tions  for  tools  are  also  specified  such  that  the  annotations 
are  in  Ada  comments.  Processing  can  then  be  accomplished 
by  another  tool  as  well  as  by  an  Ada  compiler. 

To  summarize  the  IEEE  working  group's  consensus  at  the 
present  time,  the  major  issues  facing  Ada  as  a  PDL  revolve 
around  the  use  of  Ada  extensions.  The  alternatives  for  aug¬ 
menting  Ada  with  constructs  fall  into  two  distinct  classes: 
those  that  are  compatible  with  Ada  compilers  (comments 
and  pragmasi.  and  those  that  are  not  ipseudo-code  and  free 
text  i  Extensions  that  use  comments  and/or  pragmas  have 
the  advantage  that  an  Ada  compiler  can  be  used  to  process 
the  design  language  text,  and  that  the  design  documentation 
can  be  combined  with  its  implementation.  Although  pseudo¬ 
code  or  natural  language  may  have  its  place,  such  a  lan¬ 
guage  will  require  special  tools  and  will  present  an  added 
burden  to  the  overall  problem  of  software  management 


In  a  design  language  that  is  to  be  compatible  with  Ada  com¬ 
pilers.  comments  provide  an  indispensable  mechanism  for 
adding  new  constructs  to  the  language  Two  forms  of  com¬ 
ments  are  possible 

•  structured  -  identified  by  special  characters  to  highlight 
the  comment  as  belonging  to  the  formal  structure  of  the 

PDL 

•  unstructured  -  used  for  natural  language  explanation  of 
statements  made  in  Ada 

Associated  with  these  issues  are  the  semantic  rules  indicat¬ 
ing  which  constructs,  if  any.  are  allowed  after  the  identifica¬ 
tion  of  a  common’  Presented  in  a  different  manner,  should 
the  Ada  PDL  exactly  correspond  to  Ada  syntax  and  seman¬ 
tics  at  all  levels  of  design  or  not?  That  is.  can  the  comment 
fields  be  followed  by  text  which  in  itself  is  Ada? 

Or  should  it  be  fully  conformant  to  Ada  syntax?  This  very 
issue  is  being  discussed  and  analyzed  with  possible  resolu¬ 
tion  occurring  at  the  meeting  to  be  held  in  April.  Proponents 
of  the  rigorous  approach  to  Ada  extensions  contend  that  any¬ 
thing  that  is  inserted  in  the  comment  field  resembling  Ada 
can  be  accomplished  in  the  spirit  of  Ada  via  another  Ada 
mechanism  such  as  procedures  or  packages.  Others  contend 
that  enforcing  such  rigor  increases  the  level  of  effort  to  de¬ 
velop  the  design,  modify  the  design  and  maintain  the  design. 

The  present  product  of  the  group  is  a  draft  guideline  that  has 
evolved  over  a  period  of  two  years.  It  can  be  driven  to  a 
recommended  practice  or  even  a  trial  standard,  depending 
on  the  group  consensus.  It  is  presently  intended  to  be  used  as 
a  document  that  provides  useful  information  during  the 
process  of  evaluating  a  design  language  and  its  associated 
tools.  It  is  also  useful  to  developers  of  design  languages  and 
tools  in  evaluating  issues  such  as  features  to  be  included, 
tool  support,  life  cycle  support,  and  management  concerns 
and  practice. 


Conclusions 

The  Ada  programming  language  provides  a  means  for  bridg¬ 
ing  the  gap  in  software  development  methodology.  Ada.  by 
means  of  introducing  formalized  constructs  such  as  pack¬ 
ages.  generics,  concurrent  tasks,  exceptions,  and  separate 
program  unit  specifications,  provides  design  representation 
The  use  of  Ada  as  a  PDL  is  not  only  a  realizable  goal,  but  one 
that  has  been  achieved  by  a  number  of  organizations  at  this 
time 

The  IEEE  Ada  as  a  PDL  working  group  has  been  chartered 
to  generate,  at  the  very  least,  a  guideline  document  for  Ada- 
based  PDLtsi  The  derivation  of  a  guideline  by  the  IEEE 
working  group  will  add  to  the  momentum  of  the  Ada  effort 
and  should  help  ensure  both  the  acceptance  of  the  Ada  lan¬ 
guage  and  its  efficient  use  as  a  learning  mechanism 
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Irtroduc t  ion 

7 no  use  of  Ada  to  specify  design  information 
'■'at  been  recognized  by  the  United  States  Depart- 
sent  o*  Defense-  (UoD)  and  by  industry,  especially 
•nose  teal  wo>*k  on  government  contracts.  Ihe  DoD 
considers  Ada  as  the  first  step  in  solving  the 
"uc:  ousted  .oftware  crisis.  A  large  part  of  the 
bob's  software  crisis  is  the  soaring  cost  of  main¬ 
tain  ir,;:  software;  standardizing  on  Ada  as  an  imple¬ 
mentation  language  is  an  initial  attempt  to  cut 
those  "ia  i nt.onaru  costs.  However,  maintenance  of 
i  prewar*  is  time-consuming  and  difficult  without 
accurate  design  and  requirements  documentation. 

At  this  point,  each  contractor  uses  their  own 
:■  c tnodo I oq/,  specification  languages,  and  tools 
‘or  generating  the  design  and  requirements  docu¬ 
ment  scion. 

s.e'*e  government  contrai  ts  require  the  deli¬ 
very  c‘  the  development  tools  with  the  finished 
■  /'■tern;  r>*.ners  do  not.  As  a  result  of  this  lack 
v*  standard  izaf.  ion ,  software  engineers  trying  to 
maintain  boD's  software  must  deal  with  many  dif- 
f(  rent  methodologies  and  a  erification  languages, 
sometimes  without,  the  accompanying  tools  to  assist 

t  nr"'  . 


da  : a  rrg  i  stored  trademark  of  the  Movem¬ 

ent  -  Ada  pint  Program  ■ ' *  * i <  r  . 

/<■'■■■<  is  a  trademark  of  1  r  fermetr  ics .  Inc. 


On  the  other  hand,  most  government  contractors 
have  proprietary  methodologies,  specification  lan¬ 
guages,  and  tools  which  give  them  a  competitive- 
edge  in  bidding  on  government  contracts,  the  pri¬ 
mary  goal  of  most  methodologies  is  to  rinirize  cost 
by  improving  productivity.  Checks  and  balances  arc- 
levied  on  the  government  contractors  and  their 
methodologies  lay  the  Military  standards  and  Data 
i ten*  Descri pt ions  (DID's)  specified  in  the  con¬ 
tracts.  However,  the  standards  and  DID's  generally 
define  the  information  content  of  the  deliverables 
but  not  the  methods,  formats  including  specifica¬ 
tion  languages,  or  tools  that  are  to  be  used  to 
develop  the  deliverables. 

within  this  environment,  the  use  of  Ada  as  a 
Design  Language  (Dl )  is  currently  being  included 
in  some  government  contracts  as  a  requirement. 
However,  there  is  no  standard  for  the  use  of  Ada  as 
a  Design  Language.  As  a  result,  many  people  who 
work  for  the  government,  industry,  and  universities 
have  studied,  proposed  guidelines,  and  used  Ada  as 
a  DL.  This  paper  samples  fnv  current  research  and 
reports  key  concerns  which  have  become  apparent  in 
efforts  to  accomplish  any  level  of  standardization 
of  the  usaue  of  Ada  as  a  Dl  . 

Historical  iorspect ive 

Within  a  few  short  years  of  the  definition  of 
a  Program  Design  Language  (PDI. )  by  Caine  and  Gordon 
in  1975  [ 1 J ,  PDL  usage  had  become  an  accepted,  if 
not  preferred,  software  development  practice.  The 
origin  of  an  Ada-based  PDL,  or  Ada  Design  Language 
(DL),  dates  back  to  1981  [ 2 J .  Yet  three  years 
later,  Ada  DL's  are  still  shrouded  in  controversy 
and  debate. 

Over  this  three  year  period,  there  have  been 
many  serious  efforts  addressing  Ada  DL's.  By  early 
1988,  at  least  four  DoD  contractors  (IBM,  Harris, 
TRW,  and  Norden)  had  defined  and  were  applying  an 
Ada  Dl  to  software  developments.  In  May  1982,  the 
IEEE  Working  Group  on  Ada  as  a  PDL  was  organized  to 
address  using  Ada  as  a  PDL.  Judging  the  Ada  DL 
issue  t>  be  too  volatile  to  attempt  a  standard,  the 
ILL:  Working  Group  set  about,  to  develop  a  guideline 
rather  than  a  standard.  Concurrent  wit1'  organiza- 
t  ion  of  the  iFt.c  effort,  a  PDL /Ada  Subcommittee 
(now  the  Design  Subcommittee)  of  the  ACM  AdaTEC  was 
announced.  This  subcommittee  has  since  sponsored 
numerous  presentations,  panel  discussions  and 
"Birds  of  a  Feather"  gatherings  on  the  subject. 
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Also  in  May  1982,  the  Naval  Avionics  Center 
awarded  a  study  to  SofTech  tor  an  "Ada  Programming 
Design  Language  Survey"  (N00163-82-C-0030) .  The 
resulting  report  in  October  of  that  year  recom¬ 
mended  that  "the  Navy  not  adopt  a  single  Ada  PDL 
but  rather  promote  the  use  of  an  Ada-based  PDL  and 
adopt  guidelines  for  development  of  PDL's."  [3] 
This  effort  also  determined  that  there  was  "no 
concensus  on  what  an  Ada  PDL  should  consist  of  or 
how  it  should  be  used."  [3] 

Two  years  of  debate  since  the  flurry  of  ac¬ 
tivity  in  May  1982  has  not  resulted  in  an  Ada  DL 
standard  being  generated,  nor  even  approved. 
Guidelines  are  not  emerging  from  the  IEEE  and  Navy 
efforts  (though  work  is  continuing).  The  growing 
list  of  Ada  OL  dialects  has  grown  to  include  those 
of  at  least  sixteen  corporations  and  half  a  dozen 
universities.  Dozens  of  papers  have  been  pub¬ 
lished  on  the  subject,  elaborating,  but  rarely 
introducing  new  issues. 

Most  blame  these  disappointing  results  on  a 
lack  of  maturity,  indicating  that  "much  more  ex¬ 
perience  in  the  use  of  Ada-based  PDL's  is 
needed..."  [ 4 J  This  paper  reflects  the  authors' 
concern  over  the  seemingly  slow  progress  in  the 
standardization  of  Ada  DL 1 s  and  examines  key  lan¬ 
guage  issues,  focusing  on  areas  of  community  di¬ 
vergence.  Finally  the  paper  will  examine  the 
underlying  reasons  for  the  divergence  and  test  the 
hypothesis  that  Ada  DL 1 s  are  still  immature. 

Definjt ion  _of_  an  _Ada  Dl. 

A  single,  concise  definition  of  the  phrase 
"Ada  Design  Language"  has  not  been  accepted  by  the 
Ada  community.  Since  Ada  Design  Language  (DL)  is 
a  merger  of  two  languages  used  by  software  en¬ 
gineers,  Ada  and  PDL,  a  definition  of  "Ada  DL"  can 
be  determined  by  examining  the  definitions  of  Ada 
and  POL. 

Ada  is  a  computer  language  which  has  been 
developed  by  the  United  States  Department  of  De¬ 
fense.  It  is  defined  by  the  Ada  Language  Refer¬ 
ence  Manual  [4].  Druffel  has  identified  the 
qualities  of  Ada  which  support  good  software  en¬ 
gineering  practices:  “Since  Ada  was  designed  by 
software  engineers  who  intended  to  use  the  lan¬ 
guage,  it  is  not  surprising  to  find  a  number  of 
Ada  features  which  support  modern  software  engi¬ 
neering  practices.  Specifically,  Ada  provides  for 
structured  programming,  strong  data  typing,  sepa¬ 
rate  compilation,  information  hiding,  data  ab¬ 
straction,  encapsulation,  separation  of  specifica¬ 
tion  from  implementation,  separation  of  logical 
and  physical  concerns,  and  readability.  Not  sur¬ 
prisingly,  software  engineers  are  discovering  that 
Ada  provides  for  natural  expression  of  design." 

T5J 

PDL  as  defined  by  Laine  and  Gordon  is  a 
"'pidgin'  language  in  that  it  uses  the  vocabulary 
of  one  language  le.g.,  English)  and  the  overall 
syntax  of  another  (i.e.,  a  structured  programming 
language)."  (6]  Pressman  in  his  book  on  software 
engineering  adds  to  this  definition  the  following 
statement:  "The  difference  between  PDL  and  a  real 


high-level  programming  language  lies  in  the  use  of 
narrative  text  (e.g.,  English)  embedded  directly 
within  PDL  statements."  [7] 

One  can  therefore  conclude  that  the  definition 
of  Ada  DL  should  be  a  language  that  combines  the 
vocabulary  of  English  and  the  overall  syntax  of  Ada 
to  provide  a  means  for  software  engineers  to  com¬ 
municate  their  design  ideas. 

Herein  lies  the  problem.  The  term  "Ada  DL" 
has  been  interpreted  by  many  individuals  and  com¬ 
panies  to  produce  a  widely  varying  set  of  Ada  DL ' s 
which  range  from  very  tnglish-like  to  exactly  Ada. 
Many  of  the  Ada  DL's  have  been  used  for  the  devel¬ 
opment  of  deliverable  code  and  have  proven  their 
effectiveness.  Several  companies  have  developed  or 
purchased  tools  to  support  the  usage  of  their  Ada 
DL. 

This  article  summarizes  the  different  inter¬ 
pretations  of  the  tern:  "Ada  DL"  relative  to  several 
key  issues:  life  cycle  applicability  of  an  Ada  DL , 
information  expressed  by  an  Ada  DL,  relationship  of 
an  Ada  DL  to  the  Ada  language,  extension  of  the  Ada 
langua^  through  structured  commentary  and  annota¬ 
tion,  anu  relationship  between  methodology  and  Ada 
DL. 

Life  Cycle  Applicability  of  _an  Ada  DL 

The  DoD  has  made  a  major  investment  in  the 
development  of  the  Ada  language  and  therefore 
would  like  to  encourage  the  application  of  Ada 
throughout  the  development  life  cycle  rather  than 
limiting  its  appl icabi 1 ity  to  the  implementation 
chase.  The  degree  of  Ada's  applicability  to  system 
requ i rements ,  system  design,  preliminary  software 
design,  detailed  software  design,  and  hardware  de¬ 
sign  is  a  controversial  issue.  The  application  of 
Ada  early  in  the  development  of  a  system  which  will 
not  be  implemented  in  Ada  has  also  been  contro- 
versi a  I . 

Virtually  everyone  agrees  that  an  Ada  DL 
should  be  used  for  detailed  design  of  software. 

Some  feel  that  an  Ada  DL  should  be  used  strictly 
for  detailed  design:  "...designs  should  be  ex¬ 
pressed  in  Ada  when  they  have  reached  a  stage  where 
they  will  require  no  more  restructuring,  but  only 
refinements.  For  the  structured  analysis  and  de¬ 
sign  methodology,  this  stage  is  achieved  after 
structure  charts  have  been  developed,  but  not 
before."  [8J 

Some  authors  have  felt  that  an  Ada  DL  is  also 
applicable  to  preliminary  design:  a  DL  may  be  used 
during  early  design  to  "relate  the  emerging  archi¬ 
tecture  to  the  mission  and  performance  require¬ 
ments"  which  "may  require  dynamic  as  well  as 
static  checking  to  compare  design  to  performance" 
which  would  result  in  "automated  traceability  to 
mission  requirements  and  system  parameters."  [9] 

ANNA,  a  language  for  ANNotating  Ada  programs, 
extends  Ada  to  allow  the  tormal  specification  of 
the  intended  behavior  of  Ada  programs  at  all 
stages  ot  program  development.  ANNA  can  be  used 
"not  only  for  formal  verification  but  also  for 
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spec i f i cat  ion  of  program  parts  during  program  de-  arise  in  practice,  a  feature  of  Ada  used  in  a  de¬ 
sign  and  devel opment . . . . Such  specification  may  sign  may  not  map  at  all  cleanly  into  the  lmple- 

allow  the  simulation  of  interfaces  at  the  develop-  mentation  language.  This  will  probably  lead  to 
ment  stage  and  provide  the  basis  for  a  proof  of  confusion  or  arbitrary  choices  during  implementa- 

correct  use  of  a  subprogram  or  package  independent  tion,  unless  designers  are  prohibited  from  using 

of  and  prior  to  implementation,  as  well  as  a  proof  that  feature  of  Ada;  in  that  case,  it  is  question- 

of  correct  implementation."  [10]  able  whether  the  POL  is  still  Ada."  [16] 


Ada-based  languages  were  used  by  General 
Dynamics  on  a  case  study  funded  by  the  Army.  Ada 
was  used  for  the  specification  of  requirements, 
design,  and  implementation  of  the  system.  In 
particular,  the  Ada  Requirements  Methodology  (ARM) 
developed  as  part  of  the  case  study  combined  the 
use  of  data  flow  diagrams,  a  data  dictionary,  a 
logical  data  structure  model,  and  an  Ada-based 
structured  Cnglish.  They  concluded  that  ARM  could 
be  "used  to  state  and  graphically  illustrate 
system  requirements  (both  functional  and  non¬ 
functional  )...  .From  experience  gained  in  this 
project,  tne  researchers  felt  that  ARM  could  re¬ 
place  trie  old  rilitary  A-speci f icat ion  document, 
wh :ch  proved  unsuitable  in  adequately  documenting 
the  message  switch  modified  by  this  project."  [11] 

The  use  of  Ada  as  a  system  design  language 
Particularly  tor  embedded  systems  has  been  de¬ 
scribed  by  Wheeler.  He  concluded  that  the  use  of 
Ada  as  a  system  design  language  encourages  de¬ 
signers  to  use  current  practices  to  develop  better 
structures  for  their  systems,  and  its  subsequent 
use  to  implement  the  systems  preserves  those 
structures  in  the  product.  [12] 

An  Ada-based  language  has  even  been  used  to 
design  hardware.  A  Universal  Asynchronous 
Receiver  Transmitter  ( UART )  designed  by  SofTech 
using  an  Ada-based  language  resulted  in  the  follow¬ 
ing  conclusions;  "Ada  can  describe  hardware,  Ada 
can  do  hardware  design,"  and  "Ada  can  specify 
interfaces  without  knowing  the  hardware  software 
boundary."  [ 1 3 | 

As  a  result  of  these  experiences  in  applying 
an  Ada-based  language  to  various  phases  of  the 
life  cycle,  the  I E EL  Working  Group  on  Ada  as  a  PDL 
has  concluded  that  the  primary  phases  of  the  devel¬ 
opment  life  cycle  which  an  Ada  DL  is  intended  to 
support  are  system  design,  software  requirements, 
and  software  design.  The  use  of  Ada  DL’s  for 
other  purposes  such  as  specification  of  cystem  and 
hardware  requirements  is  not  ruled  out.  [14] 

virtually  everyone  agrees  that  an  Ada  DL 
should  be  used  when  the  implementation  language  is 
Ada.  The  use  of  an  Ada  DL  with  other  implementa¬ 
tions  languages  has  been  supported  by  Hart: 

Transliterations  of  Ada-based  design  (rather  than 
a  design  expressed  in  syntactically  correct  Ada) 
into  currently  available  languages  will  be  easier 
because  the  design  contains  less  syntactic  con¬ 
struction  which  must  be  changed  into  the  differing 
syntax  of  another  language;  a  tailored  Ada  PDL 
could  even  incorporate  some  syntactic  construc¬ 
tions  of  another  implementation  language."  [15] 

Problems  which  may  arise  when  Ada  is  not  the 
imp  let’ ent.it  ion  language  have  been  described  by 
A  Is  tad:  In  many  cases  which  ray  be  expected  to 


Implementation  of  an  Ada-based  DL  in  Jovial 
has  been  researched  by  Bein.  He  recognized  that 
"certain  Ada  features  do  not  translate  'nicely1 
into  Jovial.  Cither  the  use  of  these  features 
needs  to  be  constrained,  or  the  goal  of  close 
correspondence  between  design  and  implementation 
needs  to  be  sacrificed  to  some  extent."  [17] 

The  IEEE  Working  Group  on  Ada  as  a  PDL  has 
made  the  following  recommendation:  "While  an  Ada 
DL  must  support  the  design  of  systems  implemented 
in  Ada,  it  should  not  preclude  developments  not  in 
Ada.  The  Ada  DL  should  support  implementations  in 
other  languages  provided  that  proper  user  instruc¬ 
tions  are  available.  A  Coding  Standards  document 
is  recommended  which  describes  in  detail  the  recom¬ 
mended  implementation  for  the  various  DL  statements 
and  constructs."  [14] 

In  summary,  the  degree  of  applicability  of  Ada 
throughout  all  phases  of  the  development  life  cycle 
is  still  being  debated.  Yet  our  research  has  shown 
that  Ada-based  specification  languages  including 
Ada  DL's  have  been  demonstrated  to  be  applicable  in 
most  phases  of  the  life  cycle  and  with  several 
implementation  languages. 

Information  Expressed  by  an  Ada  DL 

Historically,  PDL's  have  expressed  only  algo¬ 
rithmic  design  information.  Ada's  influence  aM 
advances  in  software  engineering  have  led  to  a 
broadening  of  the  scope  of  information  expressed  in 
a  DL .  The  complexity  and  size  of  software  systems 
being  designed  currently  require  expre.-sing  the  de¬ 
sign  of  parts  of  the  system  in  comprehensible  de¬ 
sign  units  rather  than  in  a  monolithic  design.  De¬ 
sign  units  stated  in  an  Ada  DL  must  contain  two 
types  of  information:  connectivity  with  other  de¬ 
sign  units  and  a  description  of  the  design  unit. 

The  connectivity  among  design  units  describes 
the  interrelationships  such  as  external  data  ref¬ 
erences  and  external  procedure  calls.  Explicit 
expression  of  the  coupling  between  design  units 
supports  evaluation  of  the  complexity  of  the  de¬ 
sign.  The  two  types  of  connectivity  which  must  be 
expressed  in  design  are  horizontal  connectivity 
among  units  at  the  same  level  of  design  elaboration 
and  vertical  connectivity  between  units  at  differ¬ 
ent  levels  of  design  elaboration.  [1b] 

Horizontal  connectivity  among  units  at  the 
same  level  of  design  elaboration  summarizes  ref¬ 
erences  to  externally  defined  data,  externally  de¬ 
fined  process  units  (procedures,  functions,  and 
tasks),  and  other  external  interfaces  such  as 
interfaces  with  input/output  devices  and  hardware 
interrupts.  Based  on  this  information,  the  coupl¬ 
ing  of  this  design  unit  with  the  rest  of  the  system 
can  be  measured. 


subset  or  a  programming  language  while  still  re¬ 
taining  the  concepts  needed  for  design  (rather 
than  a  programming)  language."  [1]  In  reality, 
there  is  very  little  conceptual  differences  be¬ 
tween  the  purist  view  and  this,  particularly  if 
one  views  coding  as  merely  the  final  elaboration 
of  a  design,  "replacing  abstractions  with  target 
language  statements."  [1] 

Whether  by  exclusion  or  convention,  only  cer¬ 
tain  Ada  constructs  are  applicable  to  the  early 
stages  of  design.  The  problem  arises  on  deter¬ 
mining  which  ones.  The  Navy  survey  found  "a 
definite  lack  of  consensus  on  the  exclusion  of 
any  language  feature."  [22]  Because  they  found 
that  the  "omitted  features  were  small  in  number" 
it  was  concluded  that  "there  is  little  advantage 
gained,  either  in  encouraging  design  level  docu¬ 
mentation  or  in  reducing  the  complexity  of  a  PDL 
processor,  by  omitting  these  features."  [2] 

It  one  accepts  that  the  subset  issue  is  merely 
one  of  application,  the  next  major  issue  arises  on 
whether  the  Ada  language  alone  is  sufficient  for 
al 1  level s  of  design. 

"Deviations  from  full-syntax  Ada  for  design 
are  mainly  founded  on  the  expectation  that  ex¬ 
cessive  syntax  restrictions  will  not  be  accepted 
by  the  large  veteran  populations  of  software  de¬ 
signers.  this  will  be  particularly  true  when  those 
encumbrances  (which  support  no  role  of  software  de¬ 
sign)  distract  a  designer's  attention  down  to  such 
a  petty  level  of  detail  as  tc  remove  his  perspec¬ 
tive  from,  the  needed  global  and  abstraction  planes. 
Final  design  refinements  and  coding  (which  may  be¬ 
come  synonymous  using  Ada)  are  proper  times  for 
conversions  of  syntax  simplifications  into  proper 
Ada,  and  can  be  achieved  by  trained  coders  without 
impacting  basic,  early-arrived-at  design 
decisions."  [15] 

indeed  most  current  Ada  PDL 1 s  provide  capa¬ 
bilities  to  embed  English  narrative  and  mechanisms 
for  extending  the  Ada  language  using  annotations. 
Lindley  reports:  "The  inclusion  of  English  narra¬ 
tive  is  a  key  factor  in  the  use  of  the  PDL  design 
rather  than  code.  It  is  also  important  in  pro¬ 
viding  the  designer  with  the  freedom  to  be  cre¬ 
ative.  These  advantages  outweigh  the  fact  that  the 
inclusion  of  English  narrative  in  situations  where 
comments  are  not  legal  renders  the  PDL  non-compil- 
able."  [22] 

the  primary  issue  regards  the  use  of  more 
classic  structured  English  to  describe  the  function 
of  a  program  unit's  body  in  place  of  legal  Ada  syn¬ 
tax.  While  not  rigorous,  this  approach  more 
closely  follows  the  original  intent  of  PDL's  to 
describe  a  "level  of  design  [which]  can  be  under¬ 
stood  by  people  other  than  designers."  [6]  "Anno¬ 
tations  differ  from  English  narrative  in  being  an 
addition  to  legal  Ada  constructs  rather  than  re¬ 
placing  them.  Thus,  they  can  be  more  formally  de¬ 
fined  in  both  syntax  and  semantics.  They  are  im¬ 
portant,  as  with  English  narrative,  in  encouraging 
design  and  in  aiding  the  use  of  the  PDL  description 
as  documentation.  Since  annotations  are  frequently 
implemented  as  specific  forms  of  comments,  they 


normally  do  not  prevent  the  PDL  from  being  p re¬ 
cess  ible  as  an  Ada  compiler;  however,  the  compiler 
will  not  be  able  to  check  the  validity  of  the  anno¬ 
tations."  [22] 

Because  tne  extensions  and  annotations  to  Ada 
represent  a  major  point  of  contention,  a  iron- 
thorough  discussion  of  structured  commentary  and 
annotations  is  provided  iri  a  following  section. 

Ada  DL  Compilation  and  Execution 

Because  cf  the  potential  automation  advantage 
in  using  existing  Ada  language  tools,  tne  compila¬ 
tion  and  even  execution  of  an  Ada  DL  specification 
seems  attractive.  Compi 1 abi 1 i ty  of  Ada  DL  is 
cuirently  the  most  commonly  used  contractual  def¬ 
inition  of  Ada  DL's.  Compi labi 1 i ty  is  certainly 
related  to  compatibility  with  Ada  syntax  and  seman¬ 
tics  but  the  advantages  and  disadvantages  of  com¬ 
piling  designs  are  still  being  discussed. 

A  requirement  to  be  compi lable  can  certainly 
be  met  by  Ada  DL's  which  use  exactly  (or  a  subset 
of)  legal  Ada  syntax.  "This  directly  does  not  pre¬ 
clude  the  use  of  Ada  DL  syntax  which  is  not  formal 
Ada,  but  merely  forces  all  such  instances  where  the 
DL  departs  from  Ada  to  be  coded  as  Ada  comments." 
[14]  Hence,  a  large  number  of  those  Ada  DL's  which 
extend  Ada  with  commentary  and  annotations  are 
indeed  compilable. 

"Execution  of  an  Ada  DL  is  indeed  another 
matter.  This  means  that  upon  conclusion  of  the  de¬ 
sign  specification  phase,  a  validated  and  verified 
prototype  program  already  exists,  indeed,  the  two 
are  largely  one  and  the  same."  [20]  While  design 
execution  provides  the  ultimate  in  validating  soft¬ 
ware  designs,  opponents  of  execution  of  an  Ada  D._ 
cite  the  human  factors  problems  involved  in  devel¬ 
oping  a  rigorous  executable  design.  "There  is  a 
trade-off  between  ease  of  use  and  machine  process- 
ibility.  In  order  to  be  machine  processible,  in¬ 
formation  must  be  expressed  formally  in  a  syntax 
which  may  be  unambiguously  interpreted  by  the  com¬ 
puter.  Yet  as  a  syntax  becomes  more  rigorous  and 
complete,  the  effort  to  learn  and  become  proficient 
in  the  syntax  increases."  [14] 

The  authors  have  previously  cautioned:  "It  is 
generally  agreed  that  an  intermediate  design  step 
prior  to  coding  promotes  more  accurate  problem 
analysis. . .would  it  not  be  just  as  foolhardy  to 
directly  code  Ada  from  scratch  (as  it  was  with 
FORTRAN  or  PASCAL)  without  the  benefit  of  this  in¬ 
termediate  step?"  [18] 

In  summary,  it  appears  that  the  major  issues 
regarding  the  relationship  of  an  Ada  DL  to  the  Ada 
language  are  clear.  Subsets  of  Ada  in  an  Ada  DL 
should  not  be  defined,  though  conventions  on  usage 
may  not  make  full  use  of  the  language.  Lxtensioris 
are  also  clearly  needed.  Compilation  is  recom¬ 
mended,  though  the  level  of  interpretation  and 
effectiveness  of  compiler  output,  largely  depends  o- 
other  issues.  More  work  is  needed  to  assess  Ada  Dl. 
execution. 
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data  eni.  apsu  I  ated  in  and  operated  upon  by  the  di- 
■■i.;r  unit,  must  be  defined  by  type  and  object  dec- 
la  ra  liens.  The  a  1 -jort thms  which  define  the  step- 
bf-step  operations  performed  on  the  data  must  be 
expressed.  Methodolo-ties  and  standards  require 
additional  complementary  information  which  must  be 
stated  for  each  design  unit.  The  complementary 
information  may  include  performance  requirements, 
limitations,  assumptions,  assertions,  state- 
isdcnine  representations ,  testing  requirements, 
and  any  other  pertinent  information. 

Review  of  currently  available  Ada  DL's  indi¬ 
cates  that  the  scope  of  a  traditional  POL  has  been 
broadened  by  the  addition  of  information  content. 
The  information  which  must  be  expressed  by  an  Ada 
Lit  includes  not  only  algorithmic  design  but  also 
data ,  complementary  information  required  by  method¬ 
ologies  plus  connectivity  information.  The  broad¬ 
ening  of  the  scope  of  PDL ' s  to  the  scope  of  current 
Ada  DL's  has  resulted  in  confusion  about  termin¬ 
ology  and  appl icabi 1 i ty. 

Relationship  of  Ada  DL 
to  the  Ada  Language 

The  Ada  community  has  clearly  diverged  in 
generating  a  standard  pidgin  language  merging  Ada 
with  English.  The  issue  centers  on  how  Ada-1  ike 
or  how  tnglish-like  an  Ada  DL  snould  be.  There 
are  two  major  issues: 

a.  intersection  of  the  Ada  DL  with 
Ada  syntax  and  semantics 

b.  ability  to  compile  and  even  execute 
•an  Ada  DL  specif  Station 

The  alternatives  in  eacn  of  these  areas  are  dis¬ 
cussed  below. 

Ada  Syntax  and  Semantics 

As  depicted  in  figure  i.  the  intersection  of 
an  Ada  DL  with  the  Ada  1  annua  p?  may  take  many 
ferns.  The  purists  who  pres-  r  ibr  that  the  syntax 
and  s'  ini;;:  of  an  Ada  P!  .ho*. Id  be  "»actly  Ada 


letlect  a  segment  ot  the  population  who  feel  the 
Ada  language  already  has  sufficient  capabilities 
‘or  elaborating  designs  in  a  meaningful .  readabU- 
inner.  The  Ada  Language  Reference  Manual  in  fact 
-.Idtes  that  "the  syntax  of  the  language  avoids  the 
use  o'  encoded  forms  in  favor  of  more  Lnylish-like 
constructs"  [4)  “The  significant  advantage  to  this 
approach  is  as  follows:  by  adhering  to  a  prescrib¬ 
ed  set  of  conventions,  the  program’s  design  can  be 
subjected  to  verification  from  its  earl iest  stages, 
and  indeed,  throughout  its  development."  [20j 


FIGURE  1 

Ada  DI.  and  Ada  Intersection  Possibilities 


Another  group  of  authors  feel  that  a  subset  of 
the  Ada  language  is  appropriate  as  a  DL.  "Probably 
the  greatest  advantage  to  a  design  language  which 
is  a  subset  of  a  target  language  is  that  mainten¬ 
ance  of  a  design  can  easily  (and  probably  must  and 
should)  be  part  of  maintaining  the  actual  program. 
Normal  tools  which  support  programming  languages 
are  available  for  checking  the  syntax  of  the  de¬ 
sign,  for  modifying  the  design,  etc."  [1]  By  using 
(almost)  pure  Ada  as  our  design  language  we  can 
enjoy  many  of  the  benefits  provided  by  the  Ada  com¬ 
piler  and  the  Ada  Language  System  (ALS),  as  well  as 
integrating  the  DL  program  descriptions  with  other 
software  development  tool s ....  Standard  compiler 
options  such  as  automatic  indentation  ('pretty 
printing'),  cross  reference  listing,  and  Ada  syntax 
checking  are  obvious  benefits."  (21] 

It  is  questionable  however  whether  every  Ada 
construct  is  needed  during  design.  Sammet,  Waugh 
and  Reiter  report  that  in  IBM's  case  "then-  was  a 
clearcut  decision  to  use  Ada  to  obtain  the  dual 
benefits  of  having  a  design  language  which  was  a 
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‘■structured  Commentary  and  Annotations 

I  He  IEEE  Workinq  Group  on  Ada  as  a  PDL  has 
recognized  that  two  types  of  comments  are  used  to 
extend  Ada.  'These  are  unstructured  comments  and 
structured  comments.  Unstructured  comments ...  can 
be  used  to  indicate  any  information  required  in 
the  design  process  without  the  need  for  a  formal 
structure.  These  comments  cannot  normally  be  pro¬ 
cessed  by  a  mechanical  process.  The  structured 
comment  is  a  much  more  formal  structure  and  is 
identified  by  having  an  'escape  character'  imme¬ 
diately  following  the  Ada  comment  symbol 
e.g.,  '--5',  or  ‘  — '.  I  he  escape  character 

has  two  functions.  The  first  is  to  highlight  this 
comment  as  belonging  to  the  formal  structure  of  the 
Ada  DL  and  thus  the  information  is  easily  obtain¬ 
able  by  a  reviewer  or  other  people  required  to  be 
aware  of  DL  information.  The  second  function  is 
to  indicate  to  DL  tools  that  the  comment  is  a 
structured  Ada  DL  comment  and  that  the  tool  is  re¬ 
quired  to  act  on  this  information."  [14] 

Across  the  realm  of  existing  Ada  DL's  there 
is  a  wide  variety  of  structured  commentary  and 
annotations  defined.  These  serve  to  extend  the 
Ada  language  to  better  serve  the  design  process  in 
the  fol lowing  areas: 

a.  deferred  design  features 

b.  keywords  for  structured  English 
descriptions 

c.  representation  of  complementary 
design  details 

d.  formal  assertions  and  annotations 

e.  tool  directives 

The  following  subsections  discuss  the  various 
issues  and  approaches  involved  for  the  various 
structured  commentary  mechanisms. 

Deterred  Design  Details 

Privitera  suggests:  "In  design,  and  even 
coding,  there  are  often  many  decisions  that  one 
would  like  to  postpone.  Devices  for  expressing 
deferred  decisions  are  used  when  Ada  would  nor¬ 
mally  require  us  to  express  more  than  we  actually 
know.  The  opposite  situation  can  also  occur!  We 
may  know  more  than  Ada  allows  us  to  express,  or  at 
least  express  conveniently.  In  these  situations 
we  usually  rely  upon  comments.  However,  there  are 
situations  that  recur  with  such  regularity  that 
they  should  be  handled  by  uniform  methods."  [8J 

Gabber  proposes  to  handle  deferred  design 
through  the  addition  of  a  new  lexical  element 
called  "escape"  to  the  Ada  syntax.  "The  escape 
lexical  element  consists  of  any  free  text  enclosed 
in  curly  brackets.. It  can  replace  almost  any  Ada 
syntactic  entities,  except  program  structure  key¬ 
words  'Mk  PP  ‘CrDURE,  WHILE,  IF,  END,  etc.), 
progra  uni*  names  and  parameter  lists.  As  the  de¬ 
sign  -on-esses,  the  user  refines  the  crude  design 
of  earlier  stages  by  replacing  escapes  by  more  de¬ 


tailed  constructs.  At  the  end  of  the  design  pro¬ 
cess,  when  all  escapes  are  refined  to  Ada  code,  we 
have  the  equivalent  of  full  syntax  Ada  PDL."  [23] 
Similar  approaches  to  embed  English  phrases  using 
the  "  ;  ;"  notation  may  be  found  in  many  of  the 

Ada  DL ‘s  defined  in  the  industry  today. 

Privitera  identifies  the  need  to  defer  design 
decisions  on  types,  assignments,  processing  and 
addresses.  He  proposes  the  addition  of  "certain 
' TBD ’  declarations  to  the  package  STANDARD  (hence 
making  them  globally  visible).”  [8]  Sped f ica  1  ly , 
these  include  TYPE  TBD,  VALUE  TBD,  PROCESSION  TBD 
AND  ADDRESS  TBD.  This  convention  provides  for  such 
decisions  to  be  deferred  while  still  being  legal 
Ada. 

Keywords 

Keywords  are  defined  to  augment  Ada  with  two 
primary  mechani sms :  to  allow  the  use  of  structured 
English  body  descriptions  and  to  label  important 
sections  of  text  and  Ada  declarations.  Of  those 
Ada  DL's  which  prescribe  the  use  of  structured 
English,  appropriate  Ada  keywords  are  combined  with 
English  narrative  in  the  classica1  pidgin  language. 
These  naturally  include  Ada  block  constructs  such 
as : 

begin  . . .  end; 
if  ...  then  ...  end  if; 
while  . . .  loop  . . .  end  loop; 
for  . . .  loop  . . .  end  loop; 
case  . . .  end  case ; 

Additionally,  appl icat ion-spec i f ic  keywords 
(e.g.,  SORT,  DISPLAY,  POLL,  TRANSFORM)  may  be  de¬ 
fined  in  many  strucutred  English  approaches.  The 
Harris  Ada  PDL  [18]  formalizes  these  keywords  to  be 
action  verbs  of  the  form: 

--  verb  NOUN/OBJECT  (optional  modifiers); 

Structured  English  is  defined  in  an  Ada  DL 
either  as  a  commentary  (as  with  Harris'  above)  or 
by  extending  the  Ada  syntax  with  additional  BNF 
definitions.  Norden's  NPDL/Ada  defines  "an 
ENGLISH  EXPRESS I ON  which  parallels  Ada's  EXPRESSION 
and  an  ENGLISH  STATEMENT  which  is  a  SIMPLE  STATE¬ 
MENT  alternative."  [2] 

Both  Intermetrics '  Byron  and  Harris'  Ada  PDL 
define  keywords  to  label  important  sections  of  a 
design  specification.  Byron's  keywords,  labeled 
directives,  are  recognized  by  the  presence  of  the 
fol lowing  : 


--!  (keyword):  (text) 

The  (text)  part  of  a  directive  includes  any  text 
appearing  on  the  same  line  as  the  keyword,  as  well 
as  Byron  text  from  subsequent  lines."  [24]  The 
content  of  the  text  is  defined  by  the  keyword  used 
to  identify  it.  Twelve  Byron  directives  are  de¬ 
fined  including  ALGORITHM,  EFFECTS,  ERRORS,  INVARI¬ 
ANTS,  MODIFIES,  NOTES,  OVERVIEW,  RAISES,  REQUIRES 
AND  TUNING. 
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Because  the  Harris  Ada  PDL  defines  all  commen¬ 
tary  in  a  rigid  structure,  special  delimiters  are 
not  necessary  to  distinguish  between  forms  of  anno¬ 
tation.  Keywords  are  defined  to  "efficiently  or¬ 
ganize  the  specification  information  while  being 
Ada  language  compatible  in  both  syntax  and  order- 
ing."  [13]  Here,  the  keywords  serve  to  organize 
subsections  of  both  commentary  and  Ada  language 
definition.  Harris  specification  keywords  include 
labeling  of  PROGRAM  REFERENCES,  DATA  REFERENCES, 
EXTERNAL  INTERFACES,  SOFTWARE  UNIT,  IDENTI¬ 
FICATION,  DATA  TYPE  and  OBJECT  DEFINITIONS,  and 
EXCEPTION  DECLARATIONS.  Other  keywords  define  sub¬ 
sections  to  enhance  the  definition  to  serve  as  an 
on-line  Unit  Development  Folder,  including  PRO¬ 
GRAMMING  LANGUAGE,  TIMING  AND  SIZING  INFORMATION, 
SPECIAL  TEST  REQUIREMENTS  and  COMPLIANCE. 

Compl ementary_Desi_gn  Details 

In  addition  to  satisfying  a  set  of  functional 
requi rements ,  a  software  design  must  satisfy 
numerous  other  complementary  requirements  as  the 
design  is  elaborated  or  tracing  design  elements  or 
details  back  to  the  source  requirements. 

Privitera,  for  instance,  stated  that  "require¬ 
ments  tracing  is  an  important  part  of  design  vali¬ 
dation,  but  Ada  includes  no  mechanism  for  relating 
system  modules  to  the  requirements  they  are  meant 
to  satisfy.  "  [8]  As  a  result,  many  Ada  DL's  in¬ 
clude  provisions  to  support  the  allocation  and 
traceability  of  requirements.  The  IEEE  Working 
Group  identified  several  areas  of  potential  impact: 

a.  Performance  which  includes  critical 
timeliness,  frequencies,  capacities, 
utilizations  and  limits. 

b.  fault  Tolerance  which  includes 
error  detection,  diagnosis,  handling, 
backup  and  recovery,  reliability  and 
redundancy. 

c.  Security  which  includes  multi-level 
security  constraints,  set/use  access 
restrictions,  breach  detection  and 
hand  I ing. 

d.  Distribtuion  which  includes  geo¬ 
graphical  distribution  of  processing, 
data  storage  and  access. 

e.  Adaptation  which  defines  the  need  to 
provide  flexibility  for  environment 
operation  or  user  adaptation. 

f.  Quality  including  those  requirements 
relating  to  usability,  integrity, 
efficiency,  correctness,  reliability, 
maintainability,  portability,  test¬ 
ability,  f lex ibi 1 i ty. 

formal  Assertions  and  Annotations 

Alstadt  noted:  "Ada  does  not  include  a 
method  of  making  assertions.  When  intelligently 
interspersed  with  algorithmic  statements,  asser¬ 
tions  about  the  state  ot  the  computation  or  about 


the  state  of  the  external  world  can  clarify  the 
function  carried  out  by  a  processing  segment.  Fur¬ 
thermore,  assertions  can  state  the  effect  of  a  pro¬ 
cessing  segment  not  yet  designed;  this  ability  is 
surely  an  aid  to  a  modular  design  methodology. 

This  problem  may  be  restated  as  the  inability  of 
Ada  to  specify  requirements  at  a  low  level."  [16] 

ANNA  (ANNotated  Ada)  by  Krieg-Bruckner  and 
Luckham,  is  such  a  "proposed  extension  to  Ada  to 
include  facilities  for  formally  specifying  the  be¬ 
havior  of  Ada  programs  (or  portions  thereof)  at  all 
stages  of  program  development.  Formal  comments  in 
ANNA  consist  of  virtual  Ada  text  and  annotations... 
the  inclusion  of  Ada  text  as  formal  comments-- 
called  virtual  Ada  text--gives  a  powerful  comment 
facility  without  affecting  the  execution  behavior 
of  the  underlying  Ada  program."  [10] 

ANNA  defines  Ada  extensions  in  the  form  of  a 
formal  first  order  annotation  language.  The  lan¬ 
guage  includes: 


a. 

declarative  annotations  (for  variables 
subtypes,  subprograms,  and  packages) 

b. 

statement  annotations 

c. 

exception  annotations 

d. 

visibility  annotations 

e. 

state  and  state  transition 

annotations 

Both  virtual  Ada  text  and  annotations  are  entered 
in  the  form  of  structured  Ada  commentary. 

IBM's  PDL/Ada  uses  a  similar  annotation  for 
state  machine  representation  and  for  specifying  the 
relationship  of  state  variables. 

T oo 1  Directives 

Virtually  all  Ada  DL's  prescribe  the  use  of 
Ada  DL  support  tools  in  addition  to  an  Ada  com¬ 
piler.  As  a  result,  the  need  often  arises  to  pro¬ 
vide  a  mechanism  to  embed  tool  directives  within 
the  Ada  DL  specification  (similar  to  pragmas  in 
Ada).  Candidate  impacts  to  the  Ada  DL  syntax  to 
support  automation  are: 

a.  Inclusion  of  start/end  delimiters. 

b.  Special  embedded  tool  directives. 

c.  Formatting  directives  inline. 

d.  Special  format  requirements  on  Ada 
DL  presentation. 

For  example,  Byron  defines  a  set  of  flags  to 
provide  directions  to  the  Byron  analyzer.  "Byron 
constructs  are  distinguished  by  the  prefix 
To  the  Ada  compiler,  this  is  a  comment;  to  the 
Byron  processor,  it  indicates  something  of  inter¬ 
est.  Flags  take  the  form  of  a  single  special 
character  immediately  following  the  prefix.  They 
include  >  "  and  "--!  <  "  for  code  extraction, 

and  to  control  output  formatting. [24] 
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The  Navy  study  found  that  "no  set  of  annota¬ 
tions  was  the  same  and  rarefy  did  two  sets  provide 
the  same  function  in  a  PDL  description.”  [2]  The 
need  for  extensions  and  annotations  is  clear,  but 
no  convergence  on  a  standard  set  of  extensions 
seems  possible  due  to  influence  by  the  host 
" ethcdol ouy 

Relationship  Between  Methodo  I  ogy  _and  Ada  Dl 

Design  Languages  have  historically  been 
methodology  independent.  Current  research  indi¬ 
cates  that  this  may  not  be  the  case  for  Ada  DL's. 
various  relationships  between  methodology  and  Ada 
D!  1 have  been  explored  by  different  authors. 

Privitera  has  clearly  stated  that  Ada  itself 
is  not  a  methodology:  "In  our  experience,  Ada  does 
riot  satisfy  the  requirements  of  a  methodology.  It 
certainly  provides  no  insight  on  how  problems  are 
to  be  analyzed  and,  while  there  is  guidance  of  a 
sort  in  the  desire  to  use  Ada's  system  structuring 
features  effectively,  Ada  alone  says  nothing  about 
now  to  strucutre  a  system  hierarchically,  only 
that  hierarchy  can  be  expressed;  it  says  nothing 
about  where  we  should  look  to  find  our  system 
modules,  only  that,  once  found,  they  may  be  con¬ 
veniently  written  as  program  units;  and  it  says 
nothing  about  what  parts  of  a  module  belong  in  its 
interface  and  what  parts  in  its  implementation, 
only  that,  once  identified,  these  parts  can  be 
kept  separate."  [8] 

METHODMAN  clearly  states  that  a  methodology 
is  independent  of  the  implementation  language: 
indeed,  many  of  the  requirements  for  a  software 
development  methodology  are  largely  independent 
of  the  target  programming  language."  [25] 

What  then  is  an  Ada-based  methodology?  The 
one  characteristic  that  clearly  identifies  a 
methodology  as  Ada-based  is  the  use  of  an  Ada- 
based  specification  language  for  recording  design 
and/or  requirements  information.  Because  of  the 
close  relationship  between  a  methodology  and  its 
associated  specification  languages,  the  method¬ 
ology  may  have  a  notable  impact  upon  the  syntax 
and  semantics  of  the  specification  languages.  The 
dependency  of  a  specification  language  (Ada  DL  in 
particular)  upon  its  associated  methodology  has 
been  recognized  by  several  authors. 

For  example,  IBM's  PDL/ADA  was  designed  to 
support  their  state-machine  based  methodology  as 
shown  by  the  following  quote:  "The  prime  techni¬ 
cal  focus  of  the  work  has  been  to  replace  an  ex¬ 
isting  design  language  and  notation  which  supports 
a  specific  design  methodology  with  a  design  lan¬ 
guage  based  on  Ada  without  impacting  the  method¬ 
ology."  [lj 

Clarke  et  al  proposed  a  nest-free  design 
methodology  using  the  Ada  package  feature.  They 
summarized  their  recommendation  in  the  following 
statement:  "We  contend  that  a  nest-free  program 
organization  also  improves  the  readability  of  Ada 
programs  and  facilitates  program  development. 

Using  packages  and  context  specification  to  ex¬ 


press  a  program  unit's  relationships ,  both  to  other 
program  units  and  to  data  objects,  results  in  a 
program  organization  in  which  program  units  can  be 
arranged  in  any  desired  order."  [19]  This 
approach  certainly  impacts  the  specification  of 
horizontal  connectivity  of  design  units. 

All  of  the  previously  discussed  types  of  in¬ 
formation  which  must  be  describable  by  an  Ada  DL 
may  be  affected  by  the  host  methouoiogy .  Vertical 
connectivity  is  dependent  upon  the  methodology's 
technique  for  partitioning  the  system  into  design 
units  and  whether  a  top-down  or  bottom-up  approach 
is  used.  Horizontal  connectivity  information  is 
impacted  by  the  methodology's  choice  between  nest- 
free  and  nested  program  structures.  Data  descrip¬ 
tions  and  algorithmic  descriptions  may  be  impacted 
by  a  recommended  style  (e.g.,  naming  conventions 
for  data  types)  and  by  the  means  for  deferring  de¬ 
sign  information  (e.g.,  the  use  of  {  }  as  discussed 
earlier).  The  complementary  information  typically 
contains  very  methodology-dependent  information 
such  as  IBM's  state-machine  representations.  A 
methodology  which  supports  stepwise  refinement  may 
require  the  DL  to  support  the  use  of  English 
statements  early  in  the  design  which  are  progres¬ 
sively  refined  into  syntactically  correct  Ada. 

The  Navy  survey  concluded:  "Many  of  the  dif¬ 
ferences  in  the  definitions  of  a  PDL  came  from  each 
individual's  or  each  company's  appraoch  to  program 
design."  As  a  result,  the  following  impact  on  the 
DL  was  recognized:  "For  a  highly  structured, 
tightly  integrated  methodology,  changes  to  the  PDL 
may  well  affect  the  entire  process  so  that  the  de¬ 
sign  of  the  PDL  is  to  a  large  extent  a  result  of 
decisions  made  about  other  parts  of  the  software 
design  process."  [2]  Due  to  the  increased  scope  of 
Ada  DL's,  the  DL  is  no  longer  independent  of  the 
methodology.  In  fact,  the  DL  may  be  strongly  de¬ 
pendent  upon  its  host  methodology. 

C°£c_l_us_Lon_s 

There  is  clearly  an  industry  divergence  on  the 
Ada  design  language  issue  which  is  perhaps  even 
widening  after  three  years  of  intense  study  and 
debate.  This  paper  has  investigated  major  lan¬ 
guage  concerns  in  five  areas;  our  conclusions  are 
as  follows: 

LIFE  CYCLE  APPLICABILITY:  There  have  been  suffi¬ 
cient  investigations  to  demonstrate  the  feasibility 
of  applying  an  Ada  DL  over  the  entire  life  cycle. 
Widespread  acceptance  of  this  evidence  is  due  to  a 
lack  of  maturity  in  applying  Ada  DL's  early  in  the 
1 ife  cycle. 

INFORMATION  EXPRESSED  IN  AN  ADA  DL:  The  continued 
confusion  in  this  area  is  due  to  a  fundamental 
resistance  to  change.  The  rescoping  and  redefi¬ 
nition  of  a  DL  has  naturally  occurred.  There  is  no 
technical  basis  for  significant  debate. 

RELATIONSHIP  TO  ADA:  Ada  subset  debate  is  strictly 
one  of  application  with  no  inherent  language  con¬ 
cerns.  The  need  for  compi labi 1 i ty  has  been  clear¬ 
ly  demonstrated;  differences  are  primarily  motiva- 


ted  by  a  res i stance  to  change.  Most  Ada  DL 
definitions  which  are  not  compilable  could  use 
other  proven  mechanisms  which  would  provide  equiva¬ 
lent  extensions  without  precluding  compilation. 
Maturity  of  application  is  an  issue  regarding 
execution  of  an  Ada  DL . 

STRUCIURED  COMMENTARY  AND  ANNOTATION:  Extensions 
of  this  form  are  clearly  needed.  The  current 
diversity  in  approaches  is  largely  due  to  differing 
methodologies.  Clearly  the  detail  to  which  much 
structured  commentary  is  developed  indicates  con¬ 
siderable  maturity  --  not  immaturity.  A  level  of 
convention  could  be  standardized  which  would  allow 
methodology- spec i f ic  ex  tens  ions . 

METHODOLOGY  RELATIONSHIP:  A  large  amount  of  resis¬ 
tance  to  an  Ada  DL  standard  is  due  to  the  method¬ 
ology  dependencies  in  the  various  approaches.  An 
Ada  DL  standard  does  have  the  potential  to  impact 
one's  way  of  doing  business.  Yet  other  successful 
specification  standards  have  been  developed  which 
have  not  been  unduly  cons trai ni ng .  Objectiveness 
could  result  in  a  workable  standard  being  developed. 

The  authors  conclude  that  the  hypothesis  that 
Ada  DL's  are  immature  is  largely  false  tsave  the 
specific  issues  identified  above).  The  primary 
problem  lies  in  a  basic  resistance  to  change  and  in 
methodology  sensitivity.  If  anything,  our  maturity 
in  methodologies  has  hindered  standardization  of  an 
Ada  DL. 

Bogdan,  representing  the  DoD's  point  of  view, 
has  sfated:  "From  a  government  point  of  view,  it  is 
imperative  that  we  have  one  standard."  [26]  The 
authors  agree  that  an  Ada  DL  standard  is  not  only 
feasible,  but  overdue. 
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Summary 

-The  principal  aim  of  the  Ada  effort  is 
economic  -  particularly  the  enhancement 
of  des i gner/ programmer  productivity  in 
all  parts  of  the  software  life-cycle.  A 
shift  in  system  design  practice  to 
widespread  use  of  off-the-shelf  large 
scale  Ada  software  components  would 
result  in  productivity  gains  exceeding  a 
factor  of  ten  -  far  more  than  likely  to 
result  fron  use  of  productivity 
enhancing  software  tools.  To  achieve 
widespread  use  of  o£^the-shelf  Ada 
components  requires  establishment  of  a 
software  components  industry,  and  a 
shift  in  attitudes  about  education  of 
system  designers  to  use  Ada.  This  paper 
reviews  progress  to  date.,. 

Rationale 

Ada  Objectives 

Readers  of  these  proceedings  are 
familiar  with  the  principal  aims  of  the 
Ada  language  development  effort.  Those 
aims  generally  relate  to  improvement  of 
productivity  in  all  aspects  of  planning, 
development,  installation,  and 
maintenance  of  software  intended  to  be 
embedded  in  systems  with  life-cycles 
measured  in  years  or  decades.  Even  the 
objective  to  make  possible  greater 
reliability  of  the  embedded  system 
software  translates  into  a  productivity 
aim,  since  improved  reliability  implies 
greater  des igner/maintainer  effort,  and 
greater  effort  by  those  who  manage  the 
designers  and  maintainers. 

The  design  of  the  Ada  language  itself 
addresses  especially  the  development  of 
systems  large  enough  to  require  the 
attention  of  teams  of  tens,  hundreds  or 
thousands  of  designers.  This  objective 
led  to  the  PACKAGE  construct  of  Ada,  and 
to  related  constructs  which  make 
possible  the  factoring  of  complex 
designs  into  modules  that  are  nearly 
independent  of  each  other.  The  better 
the  factoring,  the  better  is  the 
possibility  to  minimize  the  nigh 


overhead  of  coordination  and 
communication  among  lead-design  groups 
within  a  large  design  team. 

The  promotion  of  the  Ada  language  by  its 
principal  sponsor,  the  U.S.  Department 
of  Defense,  has  emphasized  standard¬ 
ization  in  the  interest  of  reduced 
duplication  of  effort.  Ada  is  unusual  in 
that  a  standard  has  been  approved  before 
the  appearance  of  widely  accepted  produc¬ 
tion  compilers  for  the  full  language.  Ey 
promoting  industry-wide  use  of  Ada,  the 
DoD  is  also  helping  to  reduce  duplica¬ 
tion  of  training.  This  should  help  to 
ensure  that  designers,  managers,  and 
supporting  programmers  can  all  talk  with 
each  other  on  the  same  terms. 


Component-Based  Design 

Jean  Ichbiah,  principal  designer  of  Ada, 
has  said  repeatedly  that  Ada  was 
designed  to  become  the  basis  of  a  new 
software  components  industry.  He  refers 
to  the  introduction  of  this  concept  by 
M.D.McIlroy  at  the  NATO  conference  in 
Garmisch  in  1968.  To  date,  the 
components  industry  objective  seems 
largely  to  have  been  ignored  in  DoD 
planning  and  promotion  of  the  language. 

The  concept  of  component-based  design  of 
a  large  system  can  perhaps  best  be 
understood  through  analogy  with 
electronic  design  as  it  is  practiced 
today,  and  as  it  has  evolved  over  the 
last  25  years.  In  the  early  60's,  most 
electronic  equipment  was  constructed 
from  scratch  using  discrete  components 
such  as  resistors,  capacitors,  and 
transistors.  The  concept  of  plug-in 
modules  had  been  introduced  with  printed 
circuit  boards,  but  there  were  no 
accepted  standards  on  interconnection  of 
circuit  boards  made  by  different  manufac¬ 
turers.  The  benefits  of  interconnection 
standards  were,  of  course,  understood  by 
the  industry,  as  illustrated  by  the 
standards  on  electron  tube  models  and 
pinout  conventions. 
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With  formal  approval  of  the  Ada  standard 
in  '567,  shortly  followed  by  formal 
validation  of  three  compilers,  the  Ada 
program  has  taken  a  major  step  toward 
maturity.  Strong  administration  of  Id 
policies  requiring  ‘he  use  of  compilers 
that  have  been  validated  should  help  to 
assure  the  portability  of  Adn  progr am s 
among  various  processors  and  run-time 
systems . 

Unfortunately,  many  designers  who  have 
started  *o  work  with  early  Ada  implemen¬ 
tations  ar'1  coming  to  realize  ‘hat  ‘he 
language  standard  leaves  much  to  the 
imagination  -  particularly  in  aspect s 
related  to  real-time  applies* ion? .  For 
example,  a  real-time  system  may  well 
require  asynchronous  responses  to 
external  events,  yet  the  standard 
permits  validation  of  compilers  which 
support  only  synchronous  responses.  To 
be  sure,  there  are  substantial 
differences  between  operational 
requirements  or;  a  large  mainframe 
machine  and  those  on  a  small  machine 
that  might  be  used  for  real-time 
control.  Perhaps  the  formal  validation 
suite  needs  to  be  extended  to  cover 
optional  tests  for  operational 
characteristics  typically  encountered 
in  real-time  work. 

An  unfortunate  conclusion  is  ‘hat  merely 
correct  use  of  the  Ada  language  in 
writing  a  large  application  system 
program  may  not  be  sufficient  to  assure 
the  portability  of  that  program.  Common 
module  interconnection  conven‘,ions  or 
standards,  whether  mandated  or  evolved 
on  a  defacto  basis,  will  also  be  needed. 
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;  n  n  ova  t  i  or.  an  d  ,]  oh  ere  a.  t  *  o  n  for  a 
number  or  years.  This  has  beer 
n  *  *  c  e  s  sary  to  a  1 1  ow  then  t  o  c  o  m  n*"  te  w  ■  t 
larye  bus.  i  resses .  T  ncreas  inrly 
s>ooh  tst>  Gated  appl  icatioss  software, 
a  t  mo  i era  tp  c  or;  Vs  ,  w :  1  1  pro v  i  ! e  be  1 1  e  r 
i  r'f  ornat  i  or.  for  mar;a  '■  '*-nr.t  decision  , 

7  h  i  r  i  nf  or-na  t  i  nri  will  allnw  tlio—  f  ' 
n'!  p  tl.oir  lW'i'.p.i,  avH  ilaMf  resouref.- 
to  their  rer-t  alvsntH'te. 

At  1  h(>  1  i"ie  ar-  r- r  f  tware 

It-ereise  t.hr'iU-Th  eenren-i.p  iT 
we  will  a  1 o  be  belter  ;0  1°  te  take 
ailvantaee  nf  the  pre.-entt  y  nrvi"-  ’ 
capabilities  of  totay':;  harlvfare. 

-ivy-  Tiro':  1  ee,  har  accurre  3  '  pra1."" 
bar  iwnre  fechnclr>:ry  Is  borne  lw  <  ■  •  '  y  * 
twe.n  ty-f  i  ve  year;:  more  advance  i  that: 

S'  0  f  t.WPfP  , 

.'»re  are  only  able  to  use  a bou 4 
of  a  computer  *  s  available  ca  par*  ‘  '  y  . 
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n  ]. 


.V  •  I  • 
~  V.  •  • 


t  ^row :  ri  .•!  It. 

■  on;?-ii  ;-:r 

’-hak  will  Hll  of  ‘h’s 

hnvo  op  our  •-  nr  ‘  a  ]  : •  t.r ue  +  ur^ ?  '••'••  <er 

41  y  ..no :  p*:  through  a  npr:^  i  n ^ 

.'  Oe  *  i  ]  a  ’":  j  or  o~>  i  •'  J :  f,  l  h  ’  '••; 

’  J  * "  *’  ’  '  ',v  ' '  ’  p ■  r* o  *  V  '  •  i  |  >■>  '  p  ;*  rv-''  *■  V- ,  ■ 

T  *’  ! us  4  :  o  -  »vol  u  t  i  op  ,  '••  a  u s e  we 

”  *- e  s  *"  ;  r  t.  •  n  •:  f r  o^  a  : -  ^ o ken  t  a  n  *  o  a 

:''TV;  •'P  •' •<*  V'.O"-  V  t  We  ha  Vf»  :\  PpO”l  or 

w  ’  ^ )"  u  r  e  n  n  1  oy  m e  n  *" ,  C  o V  o  t  s  a r  e  4  *  k  ;  s.  ■ r 
'  V  e  P  ■*■  h  e  n  p  o  {  j  n  t  r  o  p  1  i  p  p  t  ’7  ^  e  A  ^  e  p  i  f"  \  *' 
faooi  with  4  he  nrol  in** 


■  Hi, 


VI  P*? 


pr.rt?  , 


”  V-  w 


n: ; 


;;P  V*-,  v 


L  ha  t 


''T/P  a  ]  ^  j^ro  t  |jfr'''PV'  pf  1 J  P  "*  ”*  r' 1  a '•  *  o  • 

.•  •"•<'>. »r. • ,  h ol  v i  r  '  t  h  •  s  nroVl  on  r**-j  u  *  r«">s. 

"•*  *t  *  :  n  r  r  .-r  ~>4'  i j r* nr n  1  oye]  npriohy  ar  1 

‘  v  ;  rn  i  nr  of  our  eluca  +  1  ouu  ] 


:  i  je  ]  ik;<'  or*  will  pp‘Ji  !?pop1p  whose 

e  j  j  '*‘•4  •*•  ;  nr  ^  +  p P c;  f :  p f P P n  i  i  p,  p  WP  1  t  i  r ur 

‘i f" 1  *■  h^o  *  i  ~  ,  nn<i  rminutor  1  i  t^riry, 

’Z  'm  'v;  +  pr  iri  jp  y  !  p  *■  a r  t  \  n tr  i  n  A. h o 
'  r  ■’irv  pf,  n  "■  i  &  x t. ^ p.  'i  i  n 7hr/v)  rh 

r*  i'  1  1  ( » :ro  f  *1]  i  P  P<»  qP  i  r  ^'1  y  V-P  P  n*np 


a  */« 


■  1  ’ 


p^ r* pp p n py  ror  sucpp^ 


T’hor o  nnr  np  ‘■’.jn  ‘  f  i  pp  pia:-  *■  V-p  wra  io 
a  vh  \  1  qV  Ip  4  •">  q  1 1  p  h  ;  1  Iren  an  i  not,  j*ir?  *■ 

4  ?" n  1  :  7(5  ;  p  n p pp  p /■* n p.  o"! ;  pq  ]  ]  v 

p.  *  a  r  1  ^  ^  h  a  o  1  i  i t  p  *  p  t  <  •  # 

y.-.v  ^  ;  +  *•  1  *  nvnl  v  i  nr; 

^ '  ■* P"' n  j  f  ••■  p  a n  i  *no1  ** ■  i ' •  *•  he  *j « v- 1  n np .1 , 
A  ■  ;n  ?  r  np"  ■•;  n  r  ^wa p>".  ^ . nl ol  orv  will 

p  n  n  v'  1  » »  \y  f  ■■;>  •  .=»  j  p  p  ‘ '  ,  A  *  ”,  p  P  P  o  p.  fc.  ( 
w*»  havp  a  hoi •■*•0 -nnh •■'e  of  ^etho^s  an-j 
0:'O-;  •  1-0  v  '"Pp  f;:  ; '  P  f  *  *  r \;  \  »lOl  ’  Oy  ,  Tft’'' 

:  ••  '  * 1  i . • » •  i  '  ”  »  ■  rf ppf-.rpp;-  i  p.  oonrmu^or 


.p  i  at"  ►■>  1 , 


•  l 

'  v  », 


~<‘j  ••*  t  p'.jn  *•  •  jpo  )t  : •  o p r*  a>-p  pot-, 

',.  •  ••  r*p-*-  >- o^p* •  ■,')+:•■:  #  po^o 

1  :<  .  '  o^p  1  a  p  •  r  i '1  ,-r. a pp 

«*  a»«f.  '|Pm  -nj'"’  iij'fio'np,  7h  *  p 

*  >  r  r,i  ’  ’  op  #  a  o  o"' nut. or 

!  :  »'  f-:\ *:  o  ]  p^  pp:  t 

,  .  .  *  r> ^ i^pii4pr  lanpuaye 

■  t>  ,-np  ^PV  OthpT 

”10  ‘r«  . 

\^*j*nr.*o  r'  a  h  t  h  rr>  ir  with  u  •  , 

.;■  —  r  -p  fh*0‘-  or  t.N* 

'  1” or  ,-i *  i  w:  1  1  iio  T5*»pf op'nai 

•no  o  •  ,'■>  4  "  Or  or  hO^^l'OliP!-' 

•  *  ]  Mp/O  V  'V*'m  f  >p  v;  '•.  p  v  f 

‘  ; •  V-  op  o  f  v  ».p 

■  *  *  ■  •  •  •  1  'o*  ’  JO  If* 

••  *-  *  r  •  v^',1  '«*•  ”••  ar-  ! 


.  r.o  .  ‘P~' 

•V  *  1  ;  w- 


\  1  tv-i”  00-: 
v  T  ;i'r  A :  i r 


,0  *yiv  :  r  • 

'Y'n-  !  1 


‘•■‘5 f  •■'H  •  tr.  v  :  p  f, sjfj: ■  ar  J  Jrawiaokr,  A  io 

will  r»?q*i;re  that  everyone  use  the 
la-  .-oapo  t v;e  r.^ne  v/ay ,  Controversy  w^ll 
r  *■  :  1 1  ex  r  1 1  (;t  rhooli  never  he 
^  'r  '  r .  a  t  •  *  ! )  ,  ru4-  ’  will  he  C0ns  +  r>r  t  :  ve 
r r  ni  1  mt1:'  o  f  Pr :  va o.y 

A’ hat.  ohout  prW'^y?  7  feel  that 
**■!.■*  ■  i .rn in i-  i  p  Jif.pijp.pei  - n  J 

o  1  O  v*  •  r  f  Op  na  r;y  y.iapr;  t.0  O  O'”  0 

op.-po  v  rwel  1  * p  fateful  yen ^  ■  p  tere, 

••  "II  1 -i-'h,!--  of  o  j»-  ir  1 

i  ■  i p  rrjrr  a  nnl  i  pa  t  i  oni/  o**  j  u  *  pe  ‘  pva*  :  •••*-; 
of  privacy?  v,.pl  v  *  hap  a  1  rmi;  '  - 
*"  ■”*  n:->pp  .  . ja  4  a  '  a  f .  W :  •.  a  1  pe  a  i  y  o  o  p  t  a  *  r. 

f  1  rja  rsp  i'i  1  ;  n  f  opna  t.  i  rv-  a>out  ,r,af'v  rr 

:  ho  i  n  f  or 'na  t  *.  o:  ■  i  s  re  a  ill  y  .» va  i  1  n  11  r  a  r  • 

-  a  ■ ;  i  .■  p  on  tes  t ■  •  ? ,  7  h*  !a  •  r~. p  *  <•.  f ;  a  ‘ 

.'  j  r  f.wa  pe  oar  re  ore.a  te.J  4  o  or.  nve/.l-'  ‘  1  •• 

"h  *  ;e"  1  of  orf'-at  i  on  e  f  .a  p  er  p  •  t  ‘  ve  ■  •  t  ,,*•.> 

.<  e  w  m  pevep  V.  now  it.  i.  1  e  '  n  y  iop.  , 

The  courts  ha  v«-  yet  to  rep  ol  ve  t  v>> 
status  of  nr  re-p'a  p:> .  C  • ,  r  o  py  p :  »» •»  • 1 .  •  »• 

lefenJeJ?  Are  nro-nvr-  pa  1  pi •  *  a ':  1  *? 

•Vho  really  knows?  1  e  r  f  a  ’  r  ]  v-  •  ,•>  *  n>. 

J  urines  ami  lawyers,  *loftwar,a  l- a  will 
heoome  a  few  -'T-owth  f**el.j  fop  a  p  *  ‘  p  ’  •  • 
yoijny;  attorneys,  hpl  *  1  fher-o  1-  n,.- 
ure  aet.tlej,  pir-aoy  (  f  opoyra^s.  w ;  1  1 
rontiriue  to  be  a  pro1  1m, 

Thf?  Hone;  John  Silver  of  to. lay  "  e  \1 

programs  leoam-e  he  op  ehe  e;*l':ev"  e  ^ •  r  a4 
afford  them  or  feels  that  Hipy  are  p,t 
worth  the  nr:rfi  rhap”ed  ' y  * h“  verier. 
This,  trend  will  unfortunately  e  on*  i  r.ue , 

It  ?  F;  important  that  a  new  laneuape 
allow  some  r.pour*  ty  measures.  *o  protest 
a  potential  author's  irvest^^nt  nr*  ti^e 
ani  effort. 

V/  ill  row  pro yra~ s  :  •*  rn-*eess ary  *n 
t.h.»»  future?  Can  we  :  •  . *  r.  imply  mo  1  ’  fy 

*»  •<  i : •  ^  ’  r;  •-  rfp-j -r.  •.  ?  .  ,0^0  futupir-.  t:  ay 

we  will  nr  ‘  r  •»■»*»  i  ^roivrmn’-T  s  ,  '*y 

pjpp  t  ’  nr-  is-:  who  will  ^  ^k*  *  he  i  f  i  - 

~at ions?  Mew  programs  are  always 
as  t  he  r-eeip  >f  r  <  :s  ‘  ne.-s  *-s 
:  ■'•  a  *  r.  ii^ f: a t  •re  : , 
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•  H' FRA n Nl.  SYSTEM  INlFREACi;  FOR  ADA  IN'STR  FCTORS 


Donald  C.  Fuhr 


Tuskeqee  Institute 
Tuskocjee,  AL  36088 


1 NTROIH'CT I  ON 

-  Mo  :  e>  t  i  vi-  u  t  .'f  tiM<  iiiii/,  «>:  .i  proyramminy 
!  ni c.u.ice  requires  :r  ire  than  facility  with  the 
! anjuace  itself.  It  is  a  Is.’  nec a-ssary  to  deal 
wit;.  the  computer  as  personified  hv  t  lu*  operat¬ 
ing  v>t.  or1..  Tlu*  1. 00  IN  procedure  is  only  tin* 

•  :r-t  'n.iiulshako  with  the  system.  At’t  or  a 
■0,1.  ^  oss;  a !  1.00.  IN,  the  system  will  just  stare 
m >  k  stupidly  iron:  the  ORT  until  one  enters  a 
.  ortrt.smi  the  system  knows  how  to  handle.  The 
:  n :  orr:  a  i  on  reyardiny  the  opt  ions  available  at: 
this  i'  int  tills  about  six  she  1  i  -  i  nolle  s  of  re- 
ro retire  books,  diki  is  comp  1  et  e  1  v  underst  omj  by 
about  the  same  proport,  ion  ot  users  as.  tile  Ada 
l.anyunye  Reference  Manual.  As  with  .my  1  anyu.iye 
however,  it  is  possible  ratiier  quickly  to  learn 
:<•  nahle  one  to  yet  around  without  embarras- 
'ent  .  Hopetullv,  t  lie  tollowiny  information  will 
issist  users  in  dealing  with  the  Digital  VAX/ 

VMS  --pe rat  iny  sv stern,  y 


D 1 1 TA! .  J 0MMAND  1  ANt IF A;  d 

1  :emT.»  1 

A.s  tin-  dollar  siyn  blinks  b.n  k  from  the 
tune,  the  system  is  looking  !  >r  a  Diyital 
Oommand  h.myuuye  VICE)  command.  The  user  nay 
iii-.  ike  i  no  .  the  editors  to  hey  in  keviny  in  a 
:  r. ro:\,  or  to  mod  i  1  y  an  exist iny  one.  One  may 
:  1  o-  invoke  one  "t  the  utilities  to  perform 
various  predefined  operations.  One  may  even 
writ.*  a  program  in  DCF.  A  few  of  t  lie  DC I.  comm- 
i".d-.  evrvone  ru-eds  to  know  i  rt  order  to  pi  per- 
!v  r  m.ii'r  file-  and  directories  are  now  dos- 


He  lj 

Winn  all  else  Jails,  this  command  provides 
1 1  ie‘-s  to  most  of  the  ..m-line  document  at  ion  re- 
v  iidiny  DCf,.  The  first  sc  reen  is  a  list  of  all 
t  hi  *  omrands  and  u*  *  lilies.  The  prompt  "Topic^’ 
illows  the  user  to  explore  anv  of  tin-  listed 
f  p  i  I  by  tvpiny  in  the  'Th-  desiri-d.  "Subt  op  i  c?" 

p-r- Tints  i  *  - .  i .  i  tile  user  .is  deeply  as  desired  into 
the  dot  iils  avt liable.  When  >«ne  has  seen  ertouyh, 
■m  i  e  ,>ivt  Return-.  will  1 ‘.ad  h:i«  k  to  the  dollar 
ire.  ha.h  of  the  utilities  ha--  a  similar  Help 
r  .u  i  !  i  t  •  i  nc  1  u* let*,  w  thin  it. 


Show 

This  command  allows  the  user  to  find  wiiat  is 
yoiny  on  in  the  system  or  obtain  a  bearing  it  lost 
in  a  file  structure.  It.  is  used  with  one  of  a 
larye  number  of  parameters  to  accomplish  this 
t  ask . 

Show  Time -Causes  the  system  t  i’  display  the 
current  system  time.  This  should  he  t  lie  same  as 
the  wall  clock  time,  but,  for  various  reasons, 
often  is  not. 

Show  Default -Pi splays  the  name  of  the 
current  default  directory.  This  allows  the  user 
to  pinpoint  his  current  position  in  the  file 
st  ruct  ure. 

Show  Dev i ces-Di sp lays  a  list  of  all  devices 
recoyni/.eu  l>y  the  system  and  whether  or  not  they 
are  on-line  or  allocated  to  a  process.  It  also 
shows  how  manv  bid-byte  blocks  of  storaye  are  tree 
on  a  disk,  and  whether  or  not  a  tape  drive  is 
mount ed . 

Show  Process-!) i splavs  various  information 
about  your  terminal  session.  Such  inlormat ion 
as  elapsed  time,  CPF  lime,  priority,  and 
privileges  i s  available. 

Show  prot_ecl  ion-Displays  the  level  e:  access 
protection  in  effect  for  a  file,  or  that  which 
will  be  . i! forded  any  files  created  bv  the 
process . 

Show  Quota  - 1  f  disk  quotas  art.-  in  el  lecl  on 
the  disk  in  use,  this  command  will  show  how 
many  blocks  of  storaye  are  allowed  the  process, 
and  how  many  are  currently  churyed.  This  i s  the 
official  number  tracked  by  the  system,  includiny 
temporary  and  lost,  tiles  not  appear  inp  in  the 
d i rectory . 

Show  System-Produces  a  display  of  resource 
cons  limp  t  ion  information  about  all  processes 
currently  running.  If  the  system  is  providiny 
slow  response,  this  is  one  of  the  tools  used  to 
find  out  which  process  is  dominating,  the  system. 
This  displavcan  also  be  used  to  watch  the  pro- 
press  of  a  hatch  job. 

Slu>w  Pser_s-Produc.es  a  display  of  ail  t liter¬ 
al  live  users  currently  lopped  into  the  systen 
and  which  terminal  they  are  us iny. 

Set 

This  command  enables  a  user  to  chanye  various 
attrihutes  ot  the  process  or  tiles  as  desired. 

The  most  useful  of  the  SET  parameters  available 
lo  the  normal  user  are  as  follows: 

Set  Possword-A  user  mav  i  ii.inye  his  password 
.it  anv  t  ime,  without  reterence  to  or  permission 


132 


'  r-'i".  i;i V'.'iii  .  I’iii  '  di>*uld  ilwr.  ••  :•« 
i  r..'.’n  i  .it  i- 1 v  at  ter  iv  t  v  i  v  in/  a  new  .i»  n'lmt  or  anv 
hove  lain  eompr*vr.  i -^ed .  Alter  invokim*  this 
k  itu! ,  the  svst  asks  i.»r  the  old  password, 
the  Mew  psaswonl,  and  a  repeat  oi  the  new  password. 
None  ’i  t  hi*  passwords  are  e*  hoed  on  the  screen, 
and  t  tie  new  one  becomes  efteeiive  i  aimed  i  at  e  1  y . 

(he  password  is  not  available  in  clear  text  to 
anyone,  even  the  svst  etn  manager. 

Set  l)ef  au  1 1  - A1  lows  the  user  to  change  the 
-ie  1  an  1 1  directory  at  will.  It  a  user  has  a 
ilirci  t  i*rv  structure  including  several  sub¬ 
directories,  this  eliminates  the  necessity  of  in¬ 
cluding  the  ill  rectory  name  when  tvping  in  a  tile- 
name.  Programs  are  often  written  so  that  the  de¬ 
tail  It  directory  must  be  the  same  as  the  directory 
containing  the  input  and/or  output  files. 

Set  Prot eel ion-Al 1 ows  the  user  to  restrict 
or  allow  access  to  any  files  owned  by  the  pro¬ 
cess.  is  the  command  *SKT  PROTKCT 1 ON /DEFAULT  is 
«:iven,  .ill  tiles  subsequently  created  by  the  pro¬ 
ves*  will  receive  the  level  of  protection  in- 
d  i  k.  at  ed  . 

Rename 

This  command  allows  the  user  to  rename  any 
tile  or  group  of  files  owned  by  the  process.  It 
takes  the  torm:  $ RENAME  old  file  name 
new  file  name. 

!)eU*te 

Allows  the  user  to  delete  a  file  or  group 
"f  files  from  the  directory*  If  the  form 
$  DELETE /I. Of.  is  used,  the  system  displays  the 
name  of  each  tile  deleted.  If  the  form  SDELETK/ 
CONFIRM  is  used,  the  system  will  display  the 
name  ol  each  file  before  it  is  deleted  and  ask 
for  o  or  No  )  rom  the  user  as  to  whether  it 
should  really  be  deleted.  This  command  is  made 
more  powerful  by  use  of  a  "wildcard"  character, 
the  asterisk  (*).  I?  one  wants  to  delete  (or  do 
any  other  applicable  oper.it  ion  lo)  a  group  of 
t  iles  having  some  part  ol  the  filename  in  common, 
the  asterisk  is  subst  ituted  lor  the  common  part, 
allowing  the  entire  group  ol  files  to  be  dealt 
with  using  only  one  command.  For  example,  the 
command  SDKLETK  TEST.  *;*  will  delete  all 
versions  and  all  types  of  files  named  TEST. 

This  command  deletes  all  but  the  highest 
numbered  (most  recent)  version  of  the  tiles  given 
as  a  parameter,  or  in  the  default  directory  if 
no  parameter  is  given.  I l  one  wants  to  keep  more 
than  one  version,  the  form  $Pl-R(;K/KEEP=n  may  be 
used,  where  "n"  signifies  the  number  of  versions 
to  be  kept. 

SYSTEM  MESSAGES 

In  the  process  of  working  with  the  VMS 
system,  tin*  user  will  receive  system  messages 
I rom  t  ime  to  Lime.  They  always  take  the  same 
form,  and  are  usually  understandable,  hut  some¬ 
times  thev  cause  more  com  ern  than  necessary. 

The-,  take  the  form  7  FACILITY-/,- 1  DENT,  TEXT 
where  the  Facility  is  the  utility,  component,  or 


prog  ram  whith  *  .him-  I  I  he  rie.s-.uge.  i.  i  tin*  level 
1  ’  ■  -evi-r  i  t  v  whiih  m.r.  be  S  VStn  i  ess),  1  (Interm¬ 
it  ion),  W  ( Warn  ini*. ) ,  E  (error)  or  /■  (i.ital).  The 
higher  the  severity  level  ol  the  me-. -.age,  t  he 
gi  eater  the  probability  that  the  ;ul  ion  w.i  not 
completed  or  completed  incorrectly. 

I  Di-NT  is  an  abbreviation  of  the  message  text. 

TEXT  is  the  full  message.  Fverv  VAX  f.n  ility 
should  have  a  System  Messages  and  Recovery  I'r  •  - 
cedures  Manual  lo  assist  in  decoding  svslem 
messages . 

1.0(1 1  CAL  NAMES  AND  SYMBOLS 

Logical  Names 

This  concept  is  a  form  of  information  hiding, 
applied  by  Liu*  VMS  developers  to  system  device 
names.  By  consistent  use  ol  logical  names,  the 
user  may  access  a  tile  or  program  anywhere  in  the 
system  (if  allowed  by  file  protection)  without  a 
need  to  know  on  which  actual  device  it  is  stored. 
Tiu  system  manager  may  thus,  with  no  impact  on 
the  user,  move  directories  from  one  disk  to 
another  merely  by  redefining  the  logical  name  o: 
the  disk.  If  this  capability  did  not  exist, 
every  user  program  would  have  to  be  re-written  il 
tiu*  user  directory  were  moved.  Logical  names  art- 
established  by  using  various  forms  of  the 
$ DEFINE  or  SASS1CN  DC L  commands. 

Symbols 

Most  users  find  long  command  lines  difficult 
to  type  in  without  error,  and  the  system  insists 
on  a  complete  retyping  if  an  error  is  committed. 
This  is  particularly  frustrating  when  the  command 
line  is  used  frequently.  A  symbol  can  be  defined 
as  a  shorthand  expression  for  the  command  line, 
allowing  it  to  be  invoked  by  typing  just  a  few 
characters.  For  example,  SCAT  is  much  easier 
than  $P I RECTORY / S I ZE/DATE* PROTECT  I ON  if  a  more 
complete  directory  listing  is  desired.  A  symbol 
cun  also  be  defined  to  execute  an  entire  command 
procedure . 

Login  Command  Proeo dure 

The  most  convenient  way  to  define  useful 
symbols  and  logical  names  is  by  using  a  login 
command  procedure.  AU  VAX  installations  use  a 
system-wide  login  command  procedure  Lo  establish 
local  symbols,  etc.  Among  other  tilings,  the 
system  login  procedure  looks  in  the  user  directory 
lor  a  I  lie  called  LOClN.COM  and  executes  it  if 
it  is  found.  Any  user  may  create  a  personal 
LOCIN.COM  which  contains  any  instructions  to  the 
system  that  are  desired  to  be  executed  at  login 
time.  An  additional  password  or  any  shorthand 
symbols  may  be  included  to  provide  a  customised 
env i ronment . 

SYSTEM  SECURITY 

User  Authori  /.at  i  ori  F  i  1  e 

Ea cl)  user  has  one  record  in  the  User 
Authorization  File  ( UAF)  which  contains  the 
Username,  password,  privileges,  resource  quotas, 
default  directory,  and  all  other  user-unique 
i nt  ormat ion  that  governs  the  act  ions  the  user  may 
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in  the  ■  -vst  e/  -lYiirit  y 

viewpoint  ,  t  he  ki i  1 « ■  r: l  : . t  ,i  <  the  F  » tn.ia  , 

;■  i'.  •*.  *  r-.i .  and  i'-.t-r  Idem  ::  i .  .  *i  • . » ■  ■  Cod.  t i  If).  .ill 
.»•  ■*'!!, '•;  ir>  i  .  i /tied  hv  till  >Y..t  en  manager  when 

i  ni. -  T: ;  i  ••  mu-.t  !u-  .in  a  1 phanumer i > 
hsr  icier  string  io  mor«-  than  l>  iii.irs.trr>  Inn/ 

■  i  ■  ;  :,ni  w  i  f  r  i  a  1 1  •  I  t  *  ■  r  .  No  tun  um  r  :::a\  have 

t *  *  .  .word- l'!i  i  .  mi >t  he  .ni  a l phanumer i c 
•  at  : r  i  i-r  s?rin>’  :tn  mori  Hum:  H  charact  or-. 

Ii'ii:.  ••  r  ■  stiiiri.l  v,  i!  hen  Id  hr  .it  least 

'  .  t  •.  r  •  Inn.',  and  should  nut  nr  r.isi  lv 

r-  int  :  i  - !  •  t  ; : ;  v  wi.lt  iv-knnwn  ill  r  i  but  t  s  ni  the 

inrr.  lin  pa --word  nrvrr  appears  in  «  I  ear  text 
in  t  ii  system  and  in  not  echoed  nn  t  hr  screen 
wiirn  .  nt  imi.  Tin.  sv  -trn  manager  t  .in  change 
;m.'v.V'.t!,  hut  t '.m.'Mt  read  (  hem.  The  user  t  .in 
i.ini.:  should)  chan/e  his  nr  !u  r  nwn  pas-wnrh  at 
will.  !'hr  i.  n  r  r  r  i  t  username  *  password  rnnhin.it  inn 
i  -i  required  in  order  for  a  user  t  n  rain  art-ms 
t.«  tin  v.strx. 

i:.srr  Itk*nt  i  !  ie.it  i«m  IahU— Thi  s  is  a  O-digit 
n't. si  cede  which  t  hr  system  assigns  to  a  user 
prm  i  v,  ha^r.i  on  the  TIC  contained  in  the  user's 
I'AK  record.  I'hr  system  also  assigns  the  TIC  to 
all  files  created  by  t  lie  user.  The  TIC  takes 
the  lorn  ( ggg  *mnn)  where  the  first  three  digits 
denotes  the  Croup  in  which  the  user  was  placed 
hv  the  system  manager,  ami  the  last  three  digits 
denote  the  user's  Member  number  within  the  Croup. 
Until  sets  ot  three  digits  may  take  values  from 
'.MO  through  177.  Croups  000  through  010  are 
reserved  ! or  the  various  System  accounts  and 
aut  nr.-.at  i cal  1  v  bestow  the  special  privileges 
necessary  to  perform  system  management  tasks. 

Tile  .‘ther  Croups  and  all  Member  numbers  have  no 
speci  al  signifii  nice  except  that  which  a  local 
tern  manager  may  assign. 

;  i  l.  Prat  e*  i  inn 

File  protect  ion  is  delined  in  terms  of  the 
nt  it'n-,  whuh  tin-  owmr  ot  a  tile  permits  other 
iiM-r.-.  i  nr  h  ir-.e  1  :  )  l"  take  with  regard  to  the 
tile.  lie  pn.ible  ..nt  ions  are:  Read ,  Write, 
execute,  Delete.  The  user  may  allow  nr  pro- 

hi:. it  air.  d  these  actions  by  any  user  of  the 
in,  and  has  complete  lontrol  over  tliis 
itt  r  i !  nit  e  nt  tile.  Tile  c  1  asses  of  users  with 
reierence  to  a  particular  file  are:  System,  Owner, 
.  rmip  ->r  World.  A  particular  user  or  process  is 
cl  iied  in  one  of  these  categories  by  TIC  as 
rnlb-ws:  A  System  user  is  one  whose  Group  number 

i  :  auo  through  010.  The  Owner  is  the  one  whose 
’1C  t-x.i>  tlv  matches  that  of  the  file.  A  Croup 
user  is  .nn  whose  Croup  number  is  the  same  as 
that  nt  the  file.  A  World  user  is  anyone  in  the 
system.  The  default  protection  provided  by  VMS 
i  •;  S:RW‘KI),  0 :  RWKD ,  C:RI. ,  W:  (no  access) ,  which 
means  that  the  Mwikt  and  System  users  m.iv  Read, 
Writ*.,  Kxeiute,  or  Delete  the  till.  Croup  users 
nay  orilv  Read  or  Hxecut  e  tile  file,  and  no  others 
have  any  at  cess.  The  owner  ot  a  file  may  change 
this  protection  at  any  time  using  the  $SKT 
PROTECT! ON  command  and  may  change  the  default 
protection  for  tin  remainder  ot  the  terminal 
-ess  ion  bv  using,  SSKT  ■"  1  n!CTION/Df\FAlT.T.  The 


1  attit  comma  tut  is  .»  /nod  ..tin!  Mali  :>  i  in.  1 1 ; :  •  i  ■  ■ 
in  n  I. nCIN.COM  til.  nr  tin  e.  u  r  i  I  v-m  i  mb-d 

PROCESS  SCHl-m  1  INI 

In  any  t  iuie- sliar  i  up  -.v-ti-n,  tin  Imal 
'■final  i->n  i>  whin  no  user  o!  the  -•  v-.t  i 

a!  lilted  b\  the  other  U'-.ers.  Ill  tile  leal  world 
t  hi-  is  true  as  long  a.-,  tin  v-.Ii-t  i-  not  !;ea\  i 
loaded.  When  the  overall  demand  3  « » r  --y-.l  e:>  rv- 
.nuri  I-  approaches  lilt  capae  it;.-  nt  I  ll'.'-i-  resimr 
i •  v i •  r v * > n i ■  can  see  tin  le.-ult.  Out  ’•  pr-'/nss  may 
1  ■  down,  nr  rti.jv  .ippear  to  ..top  »  nt  in  lv.  The 
i-  vefv  little  lb.it  an  individual  n-er  .an  do 
about  this,  .aid  not  nun  li  men  that  the  >  vs  let:: 
manager  .an  do.  It  i>  worthwhile,  !>.aw«ver,  tor 
the  as.-r  to  know  something  about  lew  tin  VMS 
*';>rr.il  in/  -vsi  «n  .lire,  t  .  traffic  a/'onp  ill  tin 
u>ers  in  order  to  understand  what  i  happening. 

s>\.  •  ••  Jyj-» 

A  process  is  the  b.isii  ent  itv  t  •  i  it  l  in- 
Si  liedul.  r  works  nti  in  ap»»ort  i  niin/  n  <  e  -  \  ••  t  h 
CiT  and  that  the  Job  Controller  mnvi  ■  in  ai  :  e.u 
o :  memory.  Besides  svst  en:  pr.n  e  ,  then  ire 
i-asically  three  types  ni  prni.e>se  ,  e.u  i:  .0 
..hich  is  handled  Jiflerently. 

Real  Tjnr  Pjrncessi  s-A  process  t  hat  i 
normally  started  wiieti  t  lie  system  i-  /•’. -te.i  and 
runs  emit  inuously,  this  type  i  •-  used  *  r  on  u 
tasks  as  data  ac<)u  i  s  i  t  ion  t  rum  laboratory  in¬ 
strumentation  which  demand  instant  r* ■  spore. «■  win 
the  data  is  ready  without,  the  neci  .-it  tor 
wailing  tor  another  process  to  r.m.pl.'t  i  .  Re  s ! 
time  processes  are  normally  few  in  :inr:l'i-r  and 
required  very  small  amount  s  n?  CPF  t  ime.  Pin-, 
havi*  a  minimal  impact  on  I'liu  r  user-  . t  in- 
svst  cm. 

Interact  i ve  1’rocessi‘s-Tfu*  system  cri.ilis  \ 
process  for  each  :ntcra«tive  user  at  login  l  em¬ 
it  cont  imu  s  unt  i!  Ingpuit  ,  ri-gardK*.  o:  what 
the  usi*r  d(*os.  It  is  pi.'ssibK*  for  pi'm  to 

"spawn"  suhprocesses ,  hut  this  get  inn  will  not 
be  discussed  here.  The  process  is  issigued  ill 
the  quotes,  pri<>rities,  and  privilege-  .nut  nine 
in  the  user's  TAT  record.  interact  ivo  prneesse 
are  ciuiraet  er  i  xe<l  hv  largo*  amount  s  o  terminal 
I/O  compared  to  the  amount  of  CPF  t  iva  consumed' 
They  are  usually  the  greatest  soun  e  system 
cont ent ion . 

Ii.it  cli  Processes- 1 1  a  process  involve:-,  jcxe- 
cuting  an  image  (executable  program)  that  re¬ 
quires  large  amount  s  of  CPC  t  itr.c  or  «  lock  t  imi  , 
it  is  ihtrrt.iJJy  run  as  a  hatch  pro<t  -  -.  Started 
hv  means  ni'  the  DO,  S  ST  DM  IT  cirraiK! ,  it  run- 
to  compli’tion  without  further  human  iutervint  i.< 
All  l/O  opirat  intis  "ue-.t  hi  to  ,.r  :  r  ■  >r  disk  !  in 
batch  processes  arc  queued  to  rut:  in  ■  gn  :o  .  , 
and  are  normal!-.  >et  up  l"  run  in  -ui  i:  a  :  ■  i  ■  ; .  i  1 
that  lliev  n^e  only  if  .onjiis  not  reqniiid  bv 
int  i  rat  live  jol>s.  Phi  ’  t  hu  .  t  ok.  !  m*  .  i  t  •  run 
than  tin”,  would  inh  r.ul  iv«  1*.  ,  '-nt  I  he-,  have 
much  less  impact  on  "(her  system  »:  <r>.  if  Im¬ 
possible  to  est.d'lish  multiple  ...mm-  .aid  nm 
mult  iple  jobs  from  each  qmue,  !  nt  thi  nu-t  1* 
done  with  i  nit  ion,  -d:in  too  man"  bit  i.  ; • 
will  interfere  with  «.  a.  h  o!  Ini  ji.  t  i.  i-ti-i 
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:-i.  pr-  :  i .  t ; »  a  ba-.u  priori  tv  1>-r  .nvchs 

:  '  ■  «  ‘  i’’  .  normal  pro,  i-mu  ,  Mu-  ;a  i  •  >  r  it  ies 

r  ■  r  a  : .  o:  i  to  \  hivh  “!  I  >.  ior 

r.  .  ;  i:\,  ;•  r  vp  i  ...i  :> ,  tin  ;  >r  i  ■  •  r  i  t  I  cs  range  on  up 

I  .  Ill  a  norm  il  ;iV:.l  r!!l,  illt  I'l’.U'l  i  Ve  pl'oci'S.SVS 

' :  ■  i !  i  on  )  nave  .1  base  priority  oi 

u.it  .  L  have  .1  Ii.im1  prioritv  ot  i. 

1  J  .  -v  • !  1. ::  :  r  •.  1  s » normally  h.i\v  a  higher  base 
.  •  r ip f i i 


:  r  'i  1.  ■  S.  :u  du  I  i  up 

each  process  l  iul  is  ready  to  usr  tilt’  CPU 
mm  t!  in  1  I  i  r  st  -  i  n-  1  i  rst  -out  (LIFO)  queue 
;  r  ;  ■ » r  i  t  *.  .  '.'.’iivn  t  lie  process  1  urri'iu  !v  us  ini; 

t  :  i  <  •  1  i‘P  in  1  i  nqu  i  shes  iL,  t  iu*  Scheduler  checks 
.  il!  tip-  prioritv  queues  and  assigns  t  lu*  t  i  rst 
pr  p  a  .  .  in  t  ho  highest  pritirilv  <tuouo  to  tin-  (PPL' . 
‘)ipt  '[  pr-uoss  begins  to  usr  CPI’,  it  continues 
until  it  needs  to  iio  an  input /out  put  operation 
or  i.snn-'t  «cntiuuc  for  some  other  reasons,  or 
util  i!  its  allocated  time  (Quantum)  has  expired. 
Quantum,  a  time  interval  on  the  order  of  a  tew 
"i  :  !  i  .n  oiuls,  is  the  maximum  time  anv  given  pro- 
>>  •  •  ••  can  usr  the  CPU  at  one  time.  This  pre¬ 
lum-.  a  process  which  does  heavy  computation 
■  ru”.  monopo  1  i  >:  i  ng  the  CPU.  When  a  process  uses 
up  it  -  qu.sit  urn ,  it  is  queued  at  the  end  of  the 
mm  ;or  its  priority.  Quantum  is  a  system 
;  .ra: si  or  which  ran  he  changed  by  the  system 
o.iji  r,  hut  only  witii  great  care. 


! 1  r i o  r i t y  1  ’  romot i on 

The  major  problem  with  a  simple  round- robin 
scheduling  procedure  is  that  most  processes  spend 
:ore  time  doing  input/output  than  they  do 


.  in..,  and 

t  hey 

must  gain  access 

to  the  CPU 

'  i  rt  i  c  11 1  a  r 

t  inn 

c  governed  by  the 

i nput / out  put 

■  t  hey  ure 

us  i  1 

il;.- .  mil. 

,-rwise,  a 

character 

read  ! rom 

a  d 

isk,  for 

examp  1 e , 

would  be 

VMS  give 

s  L  In 

L-se  "1/0 

bound"  processes  a 

it-,  p romot 

j  on  : 

so  t  hat  i 

Lhev  mav 

use  tile  CPU 

when  :uolni.  Iii  is  does  not  impact  other  users 
to  1  : •  t  r •  opt  ihlc  degree  because  an  l/O  operation 
r  aiirt  .  only  a  tinv  ;  1  act  toil  of  a  Quantum.  It 
!  tine-.  po^-.ihU-  tor  a  proress  having  a  base 
prioritv  >1  4  to  have  an  i  nst  ant  aneous  priority 

1  hi.!.  1  u  while  it  is  doing  I/O  operations, 
ri  vi  rt  i:v.:  to  *  >r  >  when  it  is  doing  mostly 
i omjml  t  ion. 


Pro..  ;  St  al_es 

II  .>nr  i-Xi,  tiles  a  f.sliOW  SYSTKM  comm  and  , 
among  ot  hor  things  displayed  is  the  "St.it  r"  ol 
t.iili  process.  This  provides  a  -asipshot  of  the 
act  ivitv  ot  the  various  processes  and  a  clue  to 
the  overall  system  load.  There  are  nine  possible 
states  in  which  a  pro*  ess  may  be: 

CUR-Thcre  is  always  exact Iv  one  "Current” 
process,  that  is,  the  process  currently  using 
the  CPU.  Since  the  CPU  is  required  to  produce 
the  display,  the  pro,  ess  ‘.ailing  the  display  will 
alwav.  appear  as  the  Current  process. 

COM-When  a  pro, ess  has  everything  it  needs 
t  I  1, impute  exi  ept  .Kie  s  to  tile  CPU,  it  is 
"f  onput  ib  I  e" .  Anv  process  indicated  us  COM  is  in 


a  queue  and  will  be  s.  heduled  to  use  tin-  ■  PF  a: 
out  lined  above.  it  too  nanv  processes  are 
Computable,  the  CPU  is  at  or  near  satur.it  ion,  and 
no  more  users  can  lie  supported. 

LKP-lvhon  a  process  in  it  iates  an  I/O 
operation  or  some  oilier  action  that,  must  be 
completed  before  the  process  can  go  on,  a  Local 
Kvetil  llae.  is  turned  on  until  the  action  i  s 
completed.  The  process  is  indicated  as  being  in 
Local  Kvent  flag  Wait,  state  during  this  time.  An 
I/O  lioimd  proress  sj>eml.s  an  overwhelming  major  it-, 
of  i  l  s  t  i me  in  this  st  at  e  . 

PFW-Occas j ona 1 1 v  a  process  requires  another 
page  to  be  brought  into  its  working  set  and  must 
wait  for  it.  It  is  pul  in  to  Page  fault  Wait 
state  during  this  time.  See  tile  Memory  Management 
section  lor  a  more  complete  discussion  ol  this 
t  op i c . 

11 1  ii— A  process  not  showing  any  activity  for 
an  extended  length  01  time  m.iv  be  put  into  a 
Hibernate  state  by  the  Scheduler. 

COMO,  LL1T),  HI  130-Wlien  memory  become*-  nearly 
saturated,  one  or  more  processes  must  be  "Out¬ 
swapped"  I rom  memory  to  the  disk.  When  this 
occurs,  one  of  these  three  states  will  be  tssigiied 
dependin’,  on  what  the  process  was  doing  at  the 
time  it  was  swapped  out.  A  more  complete 
discussion  ot  swapping  will  be  found  in  the  Mev.orv 
Management  sort  ion. 

MWALT-O11  rare  occasions,  a  process  will 
need  a  resource  that  is  not  available  necau.-e  it 
is  being  monopolized  by  some  other  process l es ) 
which  wllj  not  release  it.  This  is  called  a 
Miscellaneous  Resource  Wait  and  almost  always 
signals  that  the  system  is  about  to  lock  up,  il 
il  has  not  already  done  so.  01  ten,  the  only  way 
to  clear  this  condition  is  to  shut  the  system 
down  and  reboot  it  . 

MKMORY  MANAULMKNi 


Virtual  Memory 

the  VAX  is  a  "Virtual  Memory"  maiiiiue.  This 
means  to  the  user  that  .1  program  need  not  lit 
into  the  amount  of  main  memory  available  in  order 
to  run.  In  fact,  il  the  program  will  lit  onto 
the  disk(s)  available,  it  can  be  run  without  anv 
special  scheduling  action  by  t  Ik-  programmer.  idle 
Scheduler  program  oi  the  operating  system  will 
take  care  of  moving  pieces  of  l he  program  in  and 
out  of  memory  as  needed.  This  docs  not  mean, 
however,  that  the  programmer  can  forget  entirely 
about  memory  considerations.  Memory  availability 
i s  the  single  most  important  fact  or  in  tht  per¬ 
formance  of  an  application  or  ol  a  particular  mix 
of  nppl icat  ions.  A  basic  understanding  oi  memory 
management  will  enable  the  user  to  help  the 
system  manager  achieve  better  performance  ot  the 
application  and  ol  the  system  as  a  whole. 


B1 ocks 

All  program  segments  and  data  are  moved 
between  disk  storage'  and  memory  in  Mocks  o*  SI 
bytes  each.  In  main  memory,  this  quantity  is 
referred  to  as  a  "page".  Most  measurements  ot 


135 


'  i'i.i  capacity  are  given  in  number  ol  blocks 
v  par*  ■- . 

W.*r  k  i Set 

fhe  most  important  concept  ot  momorv  manage- 
;i  at  ,  Working  Set  is  the  amount  ol  main  memory 
c.  i::c  iisci!  i'v  a  process  at  anv  given  time.  The 
■  'tu  rating  svstem  aut  omat  i  ca  1  1  v  adjusts  a  process's 
verkin,1  set  within  established  limits  according 
to  tile  needs  ot  the  process  and  the  other 
activilv  > >ti  tile  system.  The  system  manager  can 
c.isi  1  v  control  the  working  set  limits  at  an  over¬ 
all  svst  em  level  or  at  an  individual  process 
level . 

WSMAX-This  is  a  svstem  parameter  that 
controls  the  maximum  work  ini;  set  that  anv  pro¬ 
cess  may  have.  Individual  processes  may  be 
allowed  a  smaller  working  set,  but  t hev  may 
never  exceed  WSMAX. 

WSI)KF-Th  i  s  lAr  quota  est  abl  i  sites  the 
working  set  that  an  individu.il  process  starts 
w  it  li . 

WSiXj'i'A-Tli  i  s  l:AK  ent  rv  establishes  the 
maximum  working  set  that  a  process  may  have 
without  regard  to  anv  other  processes  on  the 
svstem.  The  user  is  guaranteed  to  he  able  to 
use  tii is  much  memory  if  it  is  needed. 

WSKXTKSD-Th is  I’AK  entry  establishes  the 
maximum  working  set  available  to  a  user  if 
sum'  u  i  ent  memory  resources  are  a  va  i  1  a  b  It*.  It 

allows  a  user  to  "borrow"  memorv  it  needed  as 
long  as  the  system  is  light Iv  loaded. 

Pag  i ng  vs  Swapping 

Pag ing-Whon  a  process  needs  a  program 
segment  or  data  not  currently  in  its  working 
set  ,  tlu*  system  executes  a  "Page  Fault"  and 
brings  in  another  page  t rom  either  the  disk  or 
from  the  bottom  of  the  Free  Page  hist  or 
Modified  Page  hist  in  memory.  If  a  process  is  at 
one  ot  the  si/e  limits  on  working  set,  the 
page-  which  has  been  in  the  working  set  longest 
will  he  pushed  out  to  make  room.  It  will  he  put 
onto  the  top  of  the  Free  or  Moditied  Page  hist 
depending  on  whether  it  has  been  modified  since 
being  brought  in  from  the  disk.  If  that  page 
is  still  in  the  hist  when  the  program  needs  it 
again,  it  can  be  obtained  very  quickly.  If  not  . 
a  much  longer  disk  I/O  operation  is  required. 

Swapping- 1 f  more  processes  are  in  memory 
than  it  will  hold,  and  they  are  all  using  their 
wSOFOTA  so  the  system  cannot  reduce  their  working 
sets,  one  or  more  of  them  must  be  Outswapped  to 
the  disk.  The  system  will  normally  select  the 
least  active  processes  to  be  swapped  until  the 
ones  left  in  memory  can  get  enough  memory  to 
f  unct ion . 

To  Page  or  to  Swap? -A  s y s t  em  ma na ge r  is 
tempted  to  simply  give  everyone  all  the  memory 
they  need,  avoiding  the  memory  management  issue 
entirely.  This  might  be  workable  in  a  svstem 
with  a  large  amount  of  memory  and  users  working 
with  FORTRAN  which  will  run  nicelv  in  200-230 
pages  of  memory.  Fven  at  that,  when  one  knows 
that  VMS  needs  730-1000  pages  of  memory,  it  is 
easy  to  see  that  a  4-Mbvte  machine  (8000  pages 
ol  memory)  will  accommodate1  onlv  about  28- id 


users  without  going  inti'  paging  or  swapping. 

When  most  of  the  users  are  working  in  Pascal  or 
Ada,  needing  300-1000  or  more  pages  ot  memory, 
the  impossibility  of  giving  everyone  all  the 
memory  they  wanL  can  be  seen.  Tlu*  choice  then 
becomes  one*  of  paging  or  swapping.  If  working 
sets  are  allowed  to  grow  ve rv  large,  an  in¬ 
dividual  process  can  work  more  efficiently  as 
long  as  it  is  in  memory,  but  if  it  needs  to  be 
outswapped,  the  entire  process  must  be  moved, 
consuming  great  amounts  of  system  resources  with 
no  productivity  except  to  free  up  memory. 
Furthermore,  when  the  process  gets  to  the  head 
of  the  CPF  queue,  it  must  be  completely  trans¬ 
ferred  back  from  the  disk,  consuming  more  un¬ 
productive  system  resources.  Swapping  is 
generally  undesirable  if  it  can  be  avoided.  If, 
on  the  other  hand,  working  sets  are  limited  too 
much,  the  system  will  spend  so  much  time  paging 
that  no  productive  work  gets  done.  Generally,  a 
good  system  manager  will  experiment  with  working 
sets  to  obtain  the  best  compromise  between  paging 
and  swapping.  If  this  still  does  not  produce 
acceptable  performance,  the  only  remaining 
solution? are  to  limit  the  number  of  processes 
allowed  to  run  at  any  one  time  or  to  buy  more 
memory 

SYSTEM  UTILITIES 

All  systems  have  a  library  of  programs 
called  utilities  which  exis*  for  the  convenience 
of  the  system  manager  or  system  users.  Many  of 
them  are  integral  parts  of  the  VMS  operating 
system  software,  some  are  written  local lv,  and 
many  are  obtained  through  the  Digital  Equipment 
Computer  I’ser's  Society  (DECUS) .  Following  are 
brief  descriptions  of  a  few  of  the  standard 
ut  i  1  i  t  i es : 

Mail 

The  Mail  utility  allows  a  user  to  send 
messages  to  another  user  or  list  of  users  on 
the  system.  If  the  addressee  is  currently 
logged  into  the  system,  a  message  announcing 
the  arrival  of  a  mail  gram  appears  on  his  screen. 
If  the  addressee  is  not  logged  in  at  the  time 
ol  transmission,  the  announcement  appears  during 
the  next  login.  To  invoke  this  utility,  the 
command  is  $MAIL,  alter  which  the  utility  gives 
a  prompt  for  another  command.  At  this  point, 
tvping  HELP  will  retrieve  the  on-line  documentat¬ 
ion  explaining  the  various  MAIL  functions. 

Phone 

This  utility  allows  two  users  to  carry  on 
a  conversation  between  their  terminals  much  as 
they  would  on  the  telephone.  It  is  invoked 
with  the  command  $PHONE,  after  which  the  normal 
HELP  facility  can  be  accessed.  In  the  interest 
o!  user- t r i end  1 i ness ,  the  commands  resemble 
those  used  on  the  telephone:  Dial,  Answer, 
Hangup,  etc.  Tlu-  Phone  utility  should  he  used 
with  i onsiderat ion.  When  a  user  dials  another, 
the  unnouni  etnenl  ot  the  call  flashes  on  the 
called  party's  s(  reen  everv  10  seconds  or  so 
until  the  call  is  answered  or  the  caller  stops 
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the  ring.  This  ran  he  most  irritat  ing  if  the 
failed  [tarty  is  in  the  middle  of  something 
requiring  concent  rat  ion.  It  might  be  worth 
knowing  that  if  a  user  executes  the  command  $SET 
TERM I NAl, /NOBROADCAST ,  the  announcement  messages 
(and  all  others)  will  be  inhibited. 

Mon it  or 

This  utility  provides  another  way  of  finding 
out  what  is  going  on  in  the  system.  It  is  in¬ 
voked  as  a  DCL  command  with  a  wide  variety  of 
parameters  and  qualifiers.  Each  command  produces 
a  terminal  display  giving  a  composite  view  of 
the  activitv  of  concern.  A  sequence  to  invest¬ 
igate  the  cause  of  a  system  slowdown  might  pro¬ 
ceed  as  follows:  1)  Enter  ^MONITOR  STATES  to 
find  out  if  processes  are  being  bottlenecked 
waiting  for  the  CPU  as  indicated  by  a  large 
number  in  COM  or  COMO  state.  2)  Enter 
SMONITOR  PROCESS /TOPCPU  to  find  out  which  users 
are  monopolizing  the  CPU.  3)  If  the  CPU 
doesn't  seem  to  be  the  problem,  enter  SMONITOR 
PROCESS/TOPFAULT  to  find  out  if  many  processes 
are  doing  an  excessive  amount  of  page  faulting, 
and  which  ones  they  are.  Monitor  can  be  used 
to  check  a  great  many  other  system  conditions. 
SHEEP  MONITOR  will  show  the  other  options. 

Backup 

This  is  the  utility  used  by  the  system 
manager  to  take  a  "dump"  of  the  disk  period¬ 
ical  1\  to  insure  file  integrity  and  restore- 
abilitv.  fn  some  systems,  the  user  is  res¬ 
ponsible  for  backing  up  his  files,  in  which 
case  detailed  instructions  should  be  available. 
Backup  is  also  the  only  way  to  copy  files  from 
one  disk  to  another  in  a  multi-disk  system. 
Otherwise,  the  normal  user  needs  to  know  that  a 
properly  managed  backup  scheme  will  ensure  that 
at  least  one  copy  of  every  file  exists  on  tape, 
and  that  it  can  be  found  in  a  few  minutes  if 
necessary . 

Account ing 

This  utility  is  of  very  little  use  to  the 
normal  user,  because  almost  all  the  functions 
require  high  privilege  to  look  at  the  records 
of  other  users.  It  is  worth  while,  however,  to 
know  that  the  system  manager  can  use  this 
utility  to  obtain  detailed  resource  consumption 
data  for  any  user  or  group  of  users  for  any 
length  of  time  desired.  This  is  useful  to 
someone  responsible  for  managing  a  group  of 
users  or  to  a  user  in  a  system  in  which  resource 
utilization  is  the  basis  for  billing. 

CONCLUSION 

This  has  been  a  brief  discussion  of  some 
features  of  the  VAX/VMS  operating  system  that  do 
not  appear  in  the  Primer,  but  which  someone 
doing  extensive  work  on  a  VAX  might  find 
useful.  It  was  not  intended  to  be  an  exhaustive 
treatment,  hut  to  provide  pointers  to 
potentially  useful  functions  and  aid  in  under¬ 
standing  some  of  the  performance-determining 


actions  of  the  system.  Svnl ax  ot  the  commands 
and  ot  her  options  not  discussed  here  can  be 
found  in  the  Help  library  or  in  the  complete 
system  documentation.  Broad  knowledge  ot  these 
topics  help  any  user  to  work  more  efficiently 
and  participate  effectively  in  the  overall  manage¬ 
ment  of  the  system  for  the  benefit  of  all  users. 
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